Proof servers

Your node checks everything it books on the XRP Ledger against proofs, and it asks a proof server for them. This page lists the servers it uses unless you name another, and shows how to run and use your own.

What a proof server is

A proof server is an XRP Ledger server, rippled's xrpld, with a small patch that adds three public methods:

validations

The validators' signatures on a recent ledger. Your node checks that enough of the validators it trusts signed that ledger.

tx_proof

Proof that a transaction is in a ledger: the ledger's header and the transaction's branch in that ledger's transaction tree.

state_proof

Proof of what a ledger holds, such as an account's balance or a trust line, and proof that it holds nothing under a key.

A plain rippled doesn't have these methods. An account pointed at one stops and waits, and says the server serves no proofs; name a proof server.

The default servers

The project runs one proof server for each network, and your node's account on that network uses it unless you name another.

Your node's own testnet books, its XRP and DSUSD, are held in its testnet account, and money moves between that account and your settlement hubs on the ledger. So all of it is checked through that account's server. The mainnet account belongs to the live realm, which a node refuses, so no node uses the mainnet server. Real money is not there yet. What's next

A server that reports a different network ID than its account's stops the account, with a message that says so. That catches a server set up for the wrong network right away.

Relied on, never trusted

Your node takes nothing a proof server says on its word. Every answer it acts on has to prove itself against a ledger that a quorum of your node's own validators signed. Your node builds that list of validators from the lists its network's publishers sign, not from the server.

• A server that lies fails the first check its answer meets. Your node counts the lie, connects again, and books nothing from it.
• A server that goes silent stalls the account until it answers again. Your node waits and says why. It never falls back to taking the server's word.
• A server holds no secret. Whoever takes one over can make it lie, which your node catches, or go quiet, which stalls your node until it comes back. Nothing more.

A server does see what your node asks about: your account on the ledger, and when your node is online to ask.

Why it works this way and what each proof covers, in the proof API.

History

Each default server keeps about two days of ledgers: at least 45,000 of them. Your node relies on a proof server to keep the last 40,000 ledgers, its history bound, so that it can prove what changed while it was away.

• Away for a shorter time: your node proves every transaction it missed and books it as usual.
• Away for longer: what lies beyond the history bound is a gap. Your node matches its books to the balances the server proves, logs a warning and counts the gap. A settlement of your own in that gap stays pending for you to look at, and is never canceled.
• A server that keeps less: if it answers that it doesn't have a ledger within the bound, the account stops and waits, and says the server's history is too short. Name another server.

When the XRP Ledger testnet is reset, the testnet server starts over about half an hour after the reset, and then needs about an hour to sync the new chain. Testnet nodes wait meanwhile and book nothing wrong.

Using your own server

Anyone can run a proof server. Your node checks every answer, so it gains nothing from a server it knows and loses nothing to one it doesn't. Running your own means nobody else sees what your node asks about, and your node doesn't wait on the project's server.

1. Build the patched xrpld. The patch, the build script and the configuration are in resources/proof-server/. The build needs Nix with flakes and a few tens of gigabytes of disk:

   $resources/proof-server/build.sh 3.5.0-rc1+proofs.1 out/

   The version is the rippled release named in patches/BASE, with +proofs.<n> after it. It writes xrpld, BUILDINFO and SHA256SUMS. You can also take the project's builds from https://storage.googleapis.com/dassie-xrpld/<version>/xrpld: you don't need to trust the binary, since your node checks every answer.

2. Configure it like the project's. Start from xrpld-testnet.cfg and validators-testnet.txt in the same directory. Keep at least 45,000 ledgers of history ([ledger_history] and online_delete): anything under your node's bound of 40,000 stalls it after an absence. Give it fast disk: syncing writes thousands of small blocks a second. And give it memory: the testnet config's [node_size] of huge holds about 13 GB, and anything smaller never finishes syncing after a restart. Give it 32 GB, so that it has room to spare.

3. Serve it over wss:// at a public address, with a certificate. Your node connects only to wss:// servers at public addresses: plain ws:// and private addresses are for development only. The project's servers keep xrpld's public ports on 127.0.0.1, behind Caddy (Caddyfile), which sets the client's address itself and drops the Forwarded and X-User headers a client sends. That keeps xrpld's limits per client, so one busy client slows down only itself.

4. Check that it serves proofs. The build version ends in +proofs.<n>, and state_proof answers:

   $curl -s https://proofs.example.com -d '{"method":"server_info"}' | jq .result.info.build_version
   $curl -s https://proofs.example.com -d '{"method":"state_proof","params":[{"keys":["<64 hex>"]}]}' | jq .result

5. Point your node's account at it. An account's server is part of the account's config, which you set with dassie setup and the phrase your node was set up with. --hub none keeps it from joining a hub you haven't joined:

   $sudo dassie setup --passphrase-file phrase.txt --hub none \
       --asset 'xrpl-testnet-account/0={"server":"wss://proofs.example.com"}'

   If schemes already settle through the account, your node takes the new server at its next start:

   $sudo systemctl restart dassie

   The config can also name faucet (an HTTPS URL, or null for none) and publishers, the validator list publishers you trust, which then replace your network's.

Three other roles name an XRP Ledger server of their own. A hub validator takes it from the xrpl fields of the file DASSIE_VALIDATOR_CONFIG names, and otherwise uses its network's default server (Validate a settlement hub). A hub's founder passes dassie hub found --xrpl, and otherwise uses the server of your node's account on that network. A market maker names its own server and trusts it (Run a market maker).

Proofs from any rippled are not there yet: the patch still has to be taken upstream. What's next

The project's servers, how they are built, set up and kept running are in resources/proof-server/README.md and the spec's Proof servers.