Peer Protocol

Servers in the XRP Ledger communicate to each other using the XRP Ledger peer protocol.

The peer protocol is the main mode of communication between servers in the XRP Ledger. All information about the behavior, progress, and connectivity of the XRP Ledger passes through the peer protocol. Examples of peer-to-peer communications include all of the following:

- Requesting a connection to other servers in the peer-to-peer network, or advertising that connection slots are available.
- Sharing candidate transactions with the rest of the network.
- Requesting ledger data from historical ledgers, or providing that data.
- Proposing a set of transactions for consensus, or sharing the calculated outcome of applying a consensus transaction set.

To set up a peer-to-peer connection, one server connects to another using HTTPS and requests an HTTP upgrade to switch to the XRPL/2.0 protocol (formerly RTXP/1.2).

Peer Discovery

The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the hardcoded public hubs. After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server makes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.

Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.

The peers method shows a list of peers your server is currently connected to.

For certain high-value servers (such as important validators) you may prefer not to have your server connect to untrusted peers through the peer discovery process. In this case, you can configure your server to use private peers only.

Peer Protocol Port

To participate in the XRP Ledger, rippled servers connect to arbitrary peers using the peer protocol. (All peers are treated as untrusted, unless they are clustered with the current server.)

Ideally, the server should be able to send and receive connections on the peer port. You should forward the port used for the peer protocol through your firewall to the rippled server.

IANA has assigned port 2459 for the XRP Ledger peer protocol, but for compatibility with legacy systems, the default rippled config file listens for incoming peer protocol connections on port 51235 on all network interfaces. If you run a server, you can configure which port(s) your server listens on using the rippled.cfg file.

Example:

[port_peer]
port = 2459
ip = 0.0.0.0
protocol = peer

Node Key Pair

When a server first starts up, it generates a node key pair to use to identify itself in peer protocol communications. The server uses its key to sign all its peer protocol communications. This makes it possible to reliably identify and verify the integrity of messages from another server in the peer-to-peer network even if that server's messages are being relayed by untrusted peers.

The node key pair is saved in the database and reused when the server restarts. If you delete the server's databases, it creates a new node key pair, effectively coming online with a different identity. To reuse the same key pair even if the databases are deleted, you can configure the server with a [node_seed] stanza. To generate a value suitable for use in the [node_seed] stanza, use the validation_create method.

The node key pair also identifies other servers for purposes of clustering or reserving peer slots. If you have a cluster of servers, you should configure each server in the cluster with a unique [node_seed] setting. For more information on setting up a cluster, see Cluster rippled Servers.