mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
Update pages explaining how to run rippled (#1442)
* Update and rename run-rippled-as-a-wallet-server.md to run-rippled-as-a-stock-server.md * Redirect from 'wallet server' to 'stock server' https://github.com/XRPLF/xrpl-dev-portal/pull/1442/files#r933780313 Co-authored-by: Rome Reginelli <rome@ripple.com> Co-authored-by: mDuo13 <mduo13@gmail.com>
This commit is contained in:
Elliot Lee
@@ -1,16 +1,16 @@
|
||||
---
|
||||
html: run-rippled-as-a-wallet-server.html
|
||||
html: run-rippled-as-a-stock-server.html
|
||||
parent: configure-rippled.html
|
||||
blurb: A multipurpose configuration for anyone integrating XRP.
|
||||
labels:
|
||||
- Core Server
|
||||
---
|
||||
# Run rippled as a Wallet Server
|
||||
# Run rippled as a Stock Server
|
||||
|
||||
A wallet server is a multipurpose configuration for `rippled`. With a wallet server, you can submit transactions to the XRP Ledger, access ledger history, and use the latest [tools](software-ecosystem.html) to integrate with XRP.
|
||||
A stock server is a multipurpose configuration for `rippled`. With a stock server, you can submit transactions to the XRP Ledger, access ledger history, and use the latest [tools](software-ecosystem.html) to integrate with XRP. It is also a server that you can use to connect a wallet with the XRPL.
|
||||
|
||||
|
||||
A wallet server does all of the following:
|
||||
A stock server does all of the following:
|
||||
|
||||
- Connects to a [network of peers](consensus-network.html)
|
||||
|
||||
@@ -18,22 +18,15 @@ A wallet server does all of the following:
|
||||
|
||||
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
|
||||
|
||||
- Participates in the [consensus process](consensus.html) as a validator
|
||||
|
||||
To participate in the [consensus process](consensus.html) as a validator, [run rippled as a validator](run-rippled-as-a-validator.html) instead.
|
||||
|
||||
|
||||
## 1. Install `rippled`
|
||||
## Install and run `rippled`
|
||||
|
||||
For more information, see [Install `rippled`](install-rippled.html).
|
||||
The default package installation installs a stock server with a small amount of transaction history. For installation steps, see [Install `rippled`](install-rippled.html).
|
||||
|
||||
## 2. Enable validation on your wallet server
|
||||
|
||||
For more information, see [Enable validation on your `rippled` server](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).
|
||||
|
||||
**Warning:** Validators should not be accessible to the public. Do not allow public WebSocket access to your wallet server or any other form of public access.
|
||||
|
||||
## 3. Provide domain verification
|
||||
|
||||
For more information, see [Provide domain verification](run-rippled-as-a-validator.html#6-provide-domain-verification).
|
||||
After installation, you can adjust how much history your server stores at a time. For steps on how to do this, see [Configure Online Deletion](configure-online-deletion.html).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
@@ -20,15 +20,17 @@ A [`rippled` server](xrpl-servers.html) running in [validator mode](rippled-serv
|
||||
|
||||
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](consensus-principles-and-rules.html#how-consensus-works).
|
||||
|
||||
It's important to understand that merely issuing validation messages does not automatically give your validator a say in the consensus process. Other servers ignore your validation messages unless they add your validator to their Unique Node List (UNL). If your validator is included in a UNL, it is a _trusted_ validator and its proposals are considered in the consensus process by the servers that trust it.
|
||||
Issuing validation messages does not automatically give your validator a say in the consensus process, so the system is not vulnerable to a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack). Other servers ignore your validation messages unless they add your validator to their Unique Node List (UNL). If your validator is included in a UNL, it is a _trusted_ validator and its proposals are considered in the consensus process by the servers that trust it.
|
||||
|
||||
Even if your validator isn't a _trusted_ validator, it stills plays an important role in the overall health of the network. These validators help set the standard that trusted validators are measured against. For example, if a trusted validator is disagreeing with a lot of these validators that aren't listed in UNLs, that might indicate a problem.
|
||||
|
||||
**Warning:** Validators should not be accessible to the public. Do not allow public WebSocket access to your validator server or any other form of public access.
|
||||
|
||||
|
||||
|
||||
## 1. Understand the traits of a good validator
|
||||
|
||||
Strive to have your validator always embody the following properties. Being a good validator helps `rippled` server operators and validator list publishers, such as [https://vl.ripple.com](https://vl.ripple.com) and [https://vl.xrplf.org](https://vl.xrplf.org), to trust your validator before adding it to their UNLs.
|
||||
Strive to have your validator always embody the following properties. Being a good validator helps `rippled` server operators and validator list publishers (such as https://vl.coil.com, https://vl.ripple.com, and https://vl.xrplf.org), to trust your validator before adding it to their UNLs.
|
||||
|
||||
- **Available**
|
||||
|
||||
@@ -36,17 +38,19 @@ Strive to have your validator always embody the following properties. Being a go
|
||||
|
||||
- **In agreement**
|
||||
|
||||
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 `rippled` release](https://github.com/ripple/rippled/tree/master) without modifications. [Watch `rippled` releases](https://github.com/ripple/rippled/releases) to be notified of new releases.
|
||||
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 `rippled` release](https://github.com/XRPLF/rippled/tree/release) without modifications. [Watch `rippled` releases](https://github.com/XRPLF/rippled/releases) and subscribe to the [Google Group](https://groups.google.com/g/ripple-server) 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](system-requirements.html), which include a fast internet connection.
|
||||
|
||||
It is possible to submit new transactions and query data using a validator, but heavy loads of API queries may make the validator less reliable at keeping up with consensus. If your API needs are light enough, then you can use a server for both purposes. Ideally, a validator should be dedicated to participating in consensus.
|
||||
|
||||
- **Identified**
|
||||
|
||||
A good validator has a clearly identified owner. Providing [domain verification](#6-provide-domain-verification) is a good start. Ideally, XRP Ledger network UNLs include validators run 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 is strongly recommended that operators use the list providers that are present in this [example file](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt).
|
||||
It is strongly recommended that operators use the list providers that are present in this [example file](https://github.com/XRPLF/rippled/blob/develop/cfg/validators-example.txt).
|
||||
|
||||
|
||||
|
||||
@@ -58,9 +62,9 @@ For more information, see [Install `rippled`](install-rippled.html).
|
||||
|
||||
## 3. Enable validation on your `rippled` server
|
||||
|
||||
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` packages) to securely generate and manage your validator keys and tokens.
|
||||
Enabling validation on your `rippled` server means providing a validator token in your server's `rippled.cfg` file. You can use the `validator-keys` tool (included in `rippled` packages) to securely generate and manage your validator keys and tokens.
|
||||
|
||||
In a location **not** on your validator:
|
||||
In a secure location **not** on your validator:
|
||||
|
||||
1. Manually build and run the `validator-keys` tool, if you don't already have it installed via a `rippled` RPM.
|
||||
|
||||
|
||||
@@ -228,6 +228,18 @@ pages:
|
||||
- en
|
||||
- ja
|
||||
|
||||
# Redirect for rename from 'wallet server' to 'stock server'
|
||||
- name: Run rippled as a Stock Server
|
||||
html: run-rippled-as-a-wallet-server.html
|
||||
template: pagetype-redirect.html.jinja
|
||||
nav_omit: true
|
||||
redirect_url: run-rippled-as-a-stock-server.html
|
||||
targets:
|
||||
- en
|
||||
# This redirect needs to be added to the Japanese target *after*
|
||||
# renaming the original file in that target and translating the changes
|
||||
# - ja
|
||||
|
||||
- name: Use Cases & Featured Projects
|
||||
template: page-uses.html.jinja
|
||||
html: uses.html
|
||||
@@ -1776,7 +1788,7 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-wallet-server.md
|
||||
- md: tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-stock-server.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
|
||||
Reference in New Issue
Block a user