mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 15:45:50 +00:00
validator tut: public hubs
This commit is contained in:
Jennifer Hasegawa
@@ -20,11 +20,15 @@ To run a `rippled` server as a validator, complete the following tasks:
|
||||
|
||||
2. [Enable validation on your `rippled` server](#enable-validation-on-your-rippled-server).
|
||||
|
||||
Beyond this, you can optionally complete the following tasks that help build trust in your validator:
|
||||
3. [Connect your validator to the network using public hubs](#connect-to-the-network-using-public-hubs).
|
||||
|
||||
At this point, you are likely running your `rippled` server as an untrusted validator. 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.
|
||||
|
||||
If you want `rippled` server operators and validator list publishers to add your validator to their UNLs, making your _untrusted_ validator a _trusted_ validator, complete the following addtional tasks that help build trust in your validator:
|
||||
|
||||
1. [Understand the traits of a good validator](#understand-the-traits-of-a-good-validator).
|
||||
|
||||
2. [Set up proxies to help protect your validator](#set-up-proxies-to-help-protect-your-validator) from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks.
|
||||
2. [Connect your validator to the network using proxies](#connect-to-the-network-using-proxies).
|
||||
|
||||
3. [Provide domain verification](#provide-domain-verification).
|
||||
|
||||
@@ -100,6 +104,42 @@ On your validator:
|
||||
|
||||
|
||||
|
||||
## Connect to the Network Using Public Hubs
|
||||
|
||||
This section applies to running a validator that you want to remain an untrusted validator. In this case, it may be more efficient for you to use public hubs to connect your validator to the network than to run stock `rippled` servers to use as proxies.
|
||||
|
||||
**Note:** If you are running a trusted validator or a validator that you want to become trusted, [connect your validator to the network using proxies](#connect-to-the-network-using-proxies) instead of public hubs.
|
||||
|
||||
As a validator operator, one of your key responsibilities is to ensure that your validator has reliable and safe connections to the XRP Ledger network. Instead of connecting to random and potentially malicious peers on the network, you can instruct your validator to connect to the network through one or more public hubs. This setup can help protect your validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks.
|
||||
|
||||
A public hub is a `rippled` server that Ripple has assessed to have a track record of embodying the following traits: ***TODO: accurate to say that Ripple assessed this?***
|
||||
|
||||
- Good bandwidth.
|
||||
- Connections to a lot of peers with good reputations. ***TODO: I imagine that the assessment included checking the behavior of the peers? Is it accurate to refer to this as "reputations"?***
|
||||
- Ability to relay messages reliably.
|
||||
|
||||
To connect your validator reliably and safely to the network using public hubs, set the following configurations in your validator’s `rippled.cfg` file.
|
||||
|
||||
1. Include the following `[ips_fixed]` stanza. The two values, `r.ripple.com 51235` and `zaphod.alloy.ee 51235`, are public hubs. This stanza tells `rippled` to always attempt to maintain peer connections with these public hubs.
|
||||
|
||||
[ips_fixed]
|
||||
r.ripple.com 51235
|
||||
zaphod.alloy.ee 51235
|
||||
|
||||
You can include the IP addresses of other `rippled` servers you trust, but _**do not include**_ servers that you don’t trust.
|
||||
|
||||
2. Include the following `[peer_private]` stanza and set it to `1`. Enabling this setting instructs your validator’s peers to not broadcast your validator’s IP address. This setting also instructs your validator to connect to only the peers configured in your `[ips_fixed]` stanza. This ensures that your validator connects to and shares its IP with only peer `rippled` servers you know and trust.
|
||||
|
||||
**Warning:** Be sure that you don't publish your validator's IP address in other ways.
|
||||
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
|
||||
With `[peer_private]` enabled, `rippled` ignores any connections suggested by the `[ips]` stanza. If you need to connect to an IP currently in your `[ips]` stanza, put it in the `[ips_fixed]` stanza instead, but _**only if you trust it**_.
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
@@ -122,15 +162,17 @@ Strive to have your validator always embody the following properties. The more o
|
||||
|
||||
A good validator has a clearly identified owner. Providing [domain verification](#provide-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](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt) with a set of recommended validators. Ripple strongly recommends using exactly this list for production servers.
|
||||
|
||||
|
||||
|
||||
## Set Up Proxies to Help Protect Your Validator
|
||||
## Connect to the Network Using Proxies
|
||||
|
||||
To help protect a validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks, set up one or more stock `rippled` servers as proxies between your validator and inbound and outbound traffic.
|
||||
This section applies to a trusted validator or a validator that you want to become trusted. In this case, Ripple recommends that you run stock `rippled` servers to use as proxies to connect your validator to the network.
|
||||
|
||||
**Note:** If you are running a validator that you want to remain an untrusted validator, it may be more efficient for you to [connect to the network using public hubs](#connect-to-the-network-using-public-hubs).
|
||||
|
||||
As a validator operator, one of your key responsibilities is to ensure that your validator has reliable and safe connections to the XRP Ledger network. Instead of connecting to random and potentially malicious peers on the network, you can set up one or more stock `rippled` servers as proxies between your validator and inbound and outbound traffic. This setup can help protect your validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks.
|
||||
|
||||
**Note:** While these servers are acting as proxies, they are not web proxies for HTTP(S) traffic.
|
||||
|
||||
@@ -144,7 +186,7 @@ To help protect a validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-
|
||||
|
||||
4. In your validator's `rippled.cfg` file:
|
||||
|
||||
1. Copy the `[ips_fixed]` IP address list you defined in the previous cluster configuration step and paste it under `[ips]`.
|
||||
1. Copy the `[ips_fixed]` IP address list you defined in the previous cluster configuration step and paste it under `[ips]`. ***TODO: I think this step is no longer required, correct? As long as you have your proxy servers in [ips_fixed] and [peer_private] enabled, you don't need [ips] set in the validator in the cluster, correct?***
|
||||
|
||||
For this purpose, the `[ips_fixed]` and `[ips]` values must be identical and contain only the IP addresses and ports of the stock `rippled` servers you clustered with your validator. This ensures that your validator connects to only the stock `rippled` servers that you control.
|
||||
|
||||
@@ -221,3 +263,21 @@ To provide domain verification:
|
||||
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](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation).
|
||||
|
||||
|
||||
|
||||
## Verify Your Connection to Network
|
||||
|
||||
Here are some methods you can use to verify that your validator has a healthy connection to the XRP Ledger network:
|
||||
|
||||
- Use the [`peers`](peers.html) command to return a list of all `rippled` servers currently connected to your validator. If the `peers` array is `null`, you don’t have a healthy connection to the network. If you've set up your validator using the instructions in this document, the `peers` array should include the same number of objects as the number of peers defined in your `[ips_fixed]` stanza. ***TODO: I have both r.ripple.com 51235 and zaphod.alloy.ee 51235 in my [ips_fixed] - and sometimes I get connect to only 1 peer. Is this a problem, or is it okay? If this is okay, I guess we can't say that the number of peers in ips_fixed and the number of peers returned will always be the same. If you are not using [peer_private] - what is a healthy minimum number of peers?***
|
||||
|
||||
- If you are running an untrusted validator, haven't already set up connections to public hubs, and are having trouble maintaining a reliable and safe connection to the network, see [Connect to the Network Using Public Hubs](#connect-to-the-network-using-public-hubs).
|
||||
|
||||
- If you are running a trusted validator, haven't already set up connections to proxies, and are having trouble maintaining a reliable and safe connection to the network, see [Connect to the Network Using Proxies](#connect-to-the-network-using-proxies).
|
||||
|
||||
- Use the [`server_info`](server_info.html) command to return some basic information about your validator. The `server_state` should be set to `proposing`. It may also be set to `full` or `validating`, but only for a few minutes before moving into `proposing`.
|
||||
|
||||
If the `server_state` does not spend the majority of its time set to `proposing`, it may be a sign that your validator is unable to fully participate in the XRP Ledger network. ***TODO: accurate?*** For more information about server states and using the `server_info` endpoint to diagnose issues with your validator, see [`rippled` Server States](rippled-server-states.html) and [Get the `server_info`](diagnosing-problems.html#get-the-server-info).
|
||||
|
||||
- Use the [`validators`](validators.html) command to return the current list of published and trusted validators used by the validator. ***TODO: Is this useful? what values should they be looking for? `result.publisher_lists.available` is `true`? `result.trusted_validator_keys` contains X values?***
|
||||
|
||||
Reference in New Issue
Block a user