mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 23:55:49 +00:00
rippled setup revisions
This commit is contained in:
mDuo13
@@ -2,6 +2,11 @@
|
||||
|
||||
The core server of the Ripple peer-to-peer network is [`rippled`](rippled-apis.html). Anyone can run their own `rippled` server (also known as a _`rippled` node_) that follows the network and keeps a complete copy of the Ripple ledger. You can even have your server perform validations and participate in the consensus process.
|
||||
|
||||
This page contains instructions for:
|
||||
|
||||
* [Installing `rippled`](#installing-rippled)
|
||||
* [Participating in the Consensus Process](#running-a-validating-node)
|
||||
|
||||
|
||||
## Types of rippled Servers ##
|
||||
|
||||
@@ -9,24 +14,9 @@ The `rippled` server software can run in several modes depending on its configur
|
||||
|
||||
* Stock node - follows the network with a local copy of the ledger.
|
||||
* Validating node - participates in consensus.
|
||||
* Stand-alone mode - for basic testing.
|
||||
* Stand-alone mode - for basic testing. Does not communicate to other `rippled` servers.
|
||||
|
||||
You can also run `rippled` as a client application for accessing [rippled APIs](rippled-apis.html) 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.)
|
||||
|
||||
|
||||
## Parallel Networks ##
|
||||
|
||||
Most of the time, we describe the Ripple peer-to-peer network as one collective, singular entity -- and that's mostly true. There is one production Ripple peer-to-peer network, and all business that takes place on Ripple occurs within the production network.
|
||||
|
||||
However, sometimes you may want to do tests and experiments without interacting with the core network. That's why Ripple started the [Ripple Test Net](https://rippletest.net/), an "alternate universe" network, which can act as a testing ground for applications and the `rippled` server itself, without impacting the business operations of everyday Ripple users. The Ripple Test Net (also known as the AltNet) has a separate supply of TestNet-only XRP, which Ripple gives away for free to parties interested in developing applications on the Test Net.
|
||||
|
||||
**Caution:** Ripple makes no guarantees about the stability of the test network. It has been and continues to be used to test various properties of server configuration, network topology, and network performance.
|
||||
|
||||
Over time, there may also be additional, smaller test networks for specific purposes.
|
||||
|
||||
### Parallel Networks and Consensus ###
|
||||
|
||||
There is no `rippled` setting that defines which network it uses. Instead, it uses the consensus of validators it trusts to know which ledger to accept as the truth. When different consensus groups of `rippled` instances only trust other members of the same group, each group continues to operate as a parallel network. Even if malicious or misbehaving nodes connect to both networks, the consensus process overrides the confusion as long as the members of each network are not configured to trust members of another network in excess of their quorum settings.
|
||||
You can also run `rippled` as a client application for accessing [`rippled` APIs](rippled-apis.html) 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.)
|
||||
|
||||
|
||||
## Reasons to Run a Stock Node ##
|
||||
@@ -52,6 +42,26 @@ Not all `rippled` nodes need to be validating nodes: trusting additional nodes f
|
||||
|
||||
If your organization runs a validating node, you may also run one or more stock nodes, 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.
|
||||
* Basically, 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 `rippled` release without modifications.
|
||||
* **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](#domain-verification) is a good start.
|
||||
|
||||
At present, Ripple, Inc. cannot recommend any validators aside from the 5 core validators run by Ripple, Inc.: these validators are included in the default `rippled` configuration. However, we are collecting data on other validators and building tools to report on their performance. For metrics on the validators currently operating, see [validators.ripple.com](https://validators.ripple.com).
|
||||
|
||||
# Installing rippled #
|
||||
|
||||
For development, you can [compile `rippled` from source](https://wiki.ripple.com/Rippled_build_instructions).
|
||||
|
||||
Production `rippled` instances can [use Ripple's binary executable](#installation-on-centosred-hat-with-yum), available from the Ripple [yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified) repository.
|
||||
|
||||
## System Requirements ##
|
||||
|
||||
@@ -69,29 +79,6 @@ Amazon EC2's m3.medium or m3.large VM sizes may be appropriate depending on your
|
||||
Naturally, a fast network connection is preferable.
|
||||
|
||||
|
||||
## Clustering ##
|
||||
|
||||
If you are running multiple `rippled` servers in a single datacenter, you can configure your nodes to operate in a cluster to maximize efficiency. Operating your `rippled` servers in a cluster provides the following benefits:
|
||||
|
||||
* Clustered nodes share the work of cryptography. If one node has verified the authenticity of a message, the other nodes in the cluster trust it and do not re-verify.
|
||||
* Clustered nodes share information about peers and API clients that are misbehaving or abusing the network. This makes it harder to attack all nodes of the cluster at once.
|
||||
* Clustered nodes always propagate transactions throughout the cluster, even if the transaction does not meet the current load-based transaction fee on some of them.
|
||||
|
||||
To enable clustering, modify the following sections of your [config file](https://github.com/ripple/rippled/blob/d7def5509d8338b1e46c0adf309b5912e5168af0/doc/rippled-example.cfg#L297-L346) for each server:
|
||||
|
||||
* List the IP addresses of each other node under the `[ips_fixed]` section.
|
||||
* Generate a unique seed (using the [`validation_create` command](rippled-apis.html#validation-seed)) for each of your nodes, and configure it under the `[node_seed]` section. The `rippled` node uses this key to sign its messages to other nodes in the peer-to-peer network. **Note:** This is a different key than the one `rippled` uses to sign ledger proposals for consensus, but it is in the same format.
|
||||
* Add the public keys (for peer communication) of each of your other nodes under the `[cluster_nodes]` section.
|
||||
|
||||
|
||||
|
||||
# Installing rippled #
|
||||
|
||||
For development, you can [compile `rippled` from source](https://wiki.ripple.com/Rippled_build_instructions).
|
||||
|
||||
Production `rippled` instances can use Ripple's binary executable, available from the Ripple yum repository.
|
||||
|
||||
|
||||
## Installation on CentOS/Red Hat with yum ##
|
||||
|
||||
This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.
|
||||
@@ -114,21 +101,15 @@ This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.
|
||||
|
||||
It can take several minutes for `rippled` to sync with the rest of the network, during which time it outputs warnings about missing ledgers. After that, you have a fully functional stock `rippled` node that you can use for local signing and API access to the Ripple peer-to-peer network.
|
||||
|
||||
|
||||
# Configuring rippled #
|
||||
|
||||
`rippled` should connect to the Ripple network with the default configuration. However, you can modify your settings by editing the `rippled.cfg` file (located at `/opt/ripple/etc/rippled.cfg` when installing `rippled` with yum).
|
||||
|
||||
See [the rippled GitHub repository](https://github.com/ripple/rippled/blob/develop/doc/rippled-example.cfg) for a description of all configuration options.
|
||||
|
||||
You will need to restart rippled for any configuration changes to take effect:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
|
||||
# Running a Validating Node #
|
||||
|
||||
Becoming a validator that participates in the network involves several steps. Initially, the network probably ignores any validations your node provides: this is called being an _untrusted validator_. Later, after the operators of other `rippled` validators add your node to their configuration, your node's validations actually contribute to the consensus process. At this point, you have become a _trusted validator_.
|
||||
Running a `rippled` validator that participates in the Consensus process is simple:
|
||||
|
||||
1. [Enable validation](#validator-setup) on your `rippled` server.
|
||||
* At first, your server is an _untrusted validator_. Others can see the validations your server issues, but they disregard them in the consensus process.
|
||||
2. Share the public key with the public, especially other `rippled` operators.
|
||||
3. When other `rippled` operators add your public key to their list of trusted nodes, you have become a _trusted validator_.
|
||||
* Also see [Properties of a Good Validator](#properties-of-a-good-validator) for best practices.
|
||||
|
||||
|
||||
## Validator Setup ##
|
||||
@@ -166,7 +147,6 @@ Network participants are unlikely to trust validators without knowing who is ope
|
||||
|
||||
### ripple.txt <a name="ripple-txt"></a> ###
|
||||
|
||||
|
||||
Publish a [ripple.txt](https://wiki.ripple.com/Ripple.txt) page at your domain with a signed SSL certificate.
|
||||
|
||||
List the validator's `validation_public_key` (generated [above](#validator-setup) in step 3) in the `[validation_public_key]` section.
|
||||
@@ -210,3 +190,46 @@ The steps below describe how to set the domain field of a validator's Ripple acc
|
||||
...
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
# Additional Configuration #
|
||||
|
||||
`rippled` should connect to the Ripple network with the default configuration. However, you can modify your settings by editing the `rippled.cfg` file (located at `/opt/ripple/etc/rippled.cfg` when installing `rippled` with yum).
|
||||
|
||||
See [the rippled GitHub repository](https://github.com/ripple/rippled/blob/develop/doc/rippled-example.cfg) for a description of all configuration options.
|
||||
|
||||
You will need to restart `rippled` for any configuration changes to take effect:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
|
||||
## Parallel Networks ##
|
||||
|
||||
Most of the time, we describe the Ripple peer-to-peer network as one collective, singular entity -- and that's mostly true. There is one production Ripple peer-to-peer network, and all business that takes place on Ripple occurs within the production network.
|
||||
|
||||
However, sometimes you may want to do tests and experiments without interacting with the core network. That's why Ripple started the [Ripple Test Net](https://rippletest.net/), an "alternate universe" network, which can act as a testing ground for applications and the `rippled` server itself, without impacting the business operations of everyday Ripple users. The Ripple Test Net (also known as the AltNet) has a separate supply of TestNet-only XRP, which Ripple [gives away for free](https://ripple.com/build/ripple-test-net/) to parties interested in developing applications on the Test Net.
|
||||
|
||||
**Caution:** Ripple makes no guarantees about the stability of the test network. It has been and continues to be used to test various properties of server configuration, network topology, and network performance.
|
||||
|
||||
Over time, there may also be additional, smaller test networks for specific purposes.
|
||||
|
||||
### Parallel Networks and Consensus ###
|
||||
|
||||
There is no `rippled` setting that defines which network it uses. Instead, it uses the consensus of validators it trusts to know which ledger to accept as the truth. When different consensus groups of `rippled` instances only trust other members of the same group, each group continues to operate as a parallel network. Even if malicious or misbehaving nodes connect to both networks, the consensus process overrides the confusion as long as the members of each network are not configured to trust members of another network in excess of their quorum settings.
|
||||
|
||||
|
||||
## Clustering ##
|
||||
|
||||
If you are running multiple `rippled` servers in a single datacenter, you can configure your nodes to operate in a cluster to maximize efficiency. Operating your `rippled` servers in a cluster provides the following benefits:
|
||||
|
||||
* Clustered nodes share the work of cryptography. If one node has verified the authenticity of a message, the other nodes in the cluster trust it and do not re-verify.
|
||||
* Clustered nodes share information about peers and API clients that are misbehaving or abusing the network. This makes it harder to attack all nodes of the cluster at once.
|
||||
* Clustered nodes always propagate transactions throughout the cluster, even if the transaction does not meet the current load-based transaction fee on some of them.
|
||||
|
||||
To enable clustering, modify the following sections of your [config file](https://github.com/ripple/rippled/blob/d7def5509d8338b1e46c0adf309b5912e5168af0/doc/rippled-example.cfg#L297-L346) for each server:
|
||||
|
||||
* List the IP addresses of each other node under the `[ips_fixed]` section.
|
||||
* Generate a unique seed (using the [`validation_create` command](rippled-apis.html#validation-seed)) for each of your nodes, and configure it under the `[node_seed]` section. The `rippled` node uses this key to sign its messages to other nodes in the peer-to-peer network. **Note:** This is a different key than the one `rippled` uses to sign ledger proposals for consensus, but it is in the same format.
|
||||
* Add the public keys (for peer communication) of each of your other nodes under the `[cluster_nodes]` section.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user