Гайд: Mainnet-нода

Как поднять собственную ноду rippled, подключённую к mainnet XRP Ledger: установка, конфигурация, работа под systemd, мониторинг и — критично — своевременное обновление, чтобы нода не стала amendment-blocked.

Про локальную ноду для разработки — гайд по standalone-ноде.

Зачем своя нода

Приложения ходят на ws://localhost — без rate-limit'ов, без доверия третьей стороне, минимальная задержка для submit и подписок
Полный контроль над глубиной истории и нагрузкой на API
Публичные кластеры (wss://xrplcluster.com, wss://s1.ripple.com) душат тяжёлых пользователей и могут отставать в нагруженные дни

Роли нод (гайд покрывает первую):

Роль	Назначение
Stock-нода	Отслеживает сеть, отдаёт API, сабмитит транзакции — то, что нужно приложению
Full-history нода	То же + полная история с леджера 32570; десятки ТБ NVMe
Валидатор	Участвует в консенсусе; отдельная церемония ключей и hardening — см. доку xrpl.org

Железо (stock-нода, 2026)

Ресурс	Минимум	Рекомендуется
CPU	4 ядра / 8 потоков, высокая частота	8+ физических ядер
RAM	32 ГБ	64 ГБ
Диск	NVMe SSD, 10k+ устойчивых IOPS. Никаких HDD и сетевых хранилищ	NVMe RAID
Объём	~50 ГБ на несколько дней истории	300+ ГБ на ~месяц (см. `online_delete`)
Сеть	100 Мбит, стабильная	1 Гбит

Расход диска определяется исключительно глубиной хранения: mainnet закрывает леджер каждые 3–5 секунд круглосуточно.

Установка (Ubuntu / Debian)

Пакеты публикуются в apt-репозитории XRP Ledger Foundation (канал stable).

Исполняемый файл переименован из rippled в xrpld, а публикация пакетов в августе 2026 переехала с repos.ripple.com на packages.xrplf.org. Старый репозиторий продолжает отвечать, но остановился на 3.3.0, поэтому узел, установленный оттуда, незаметно отстаёт на релиз. Хосту, настроенному по-старому, необходимо заменить список источников, одного apt upgrade недостаточно. /usr/local/bin/rippled остаётся symlink-ом на новый бинарник.

# зависимости: curl забирает ключ, gnupg показывает его, ca-certificates обеспечивает TLS
sudo apt update && sudo apt install -y ca-certificates curl gnupg

# ключ репозитория
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsS https://packages.xrplf.org/xrplf.asc -o /etc/apt/keyrings/xrplf.asc

# проверьте ключ прежде, чем довериться ему: добавленный без проверки ключ обесценивает подпись
gpg --show-keys /etc/apt/keyrings/xrplf.asc

Отпечаток обязан совпасть:

pub   rsa4096 2026-08-18 [SC]
      B655 4167 4122 1F78 0FBC  FBC9 AA84 D41A 11D2 9FA9

Если он отличается — продолжать нельзя.

# репозиторий — одна суита, "any main", для всех дистрибутивов
echo "deb [signed-by=/etc/apt/keyrings/xrplf.asc] https://packages.xrplf.org/repository/deb-stable any main" | \
    sudo tee /etc/apt/sources.list.d/xrplf.list

sudo apt update && sudo apt -y install xrpld

Пакет устанавливает:

Путь	Назначение
`/usr/bin/xrpld`	бинарник
`/etc/xrpld/xrpld.cfg`	основной конфиг
`/etc/xrpld/validators.txt`	источник UNL (списка доверенных валидаторов)
`/usr/lib/systemd/system/xrpld.service`	systemd-юнит
`/var/lib/xrpld/`	базы данных (сюда монтируйте NVMe-том)

Конфигурация

Правится /etc/xrpld/xrpld.cfg. Продакшен-скелет для ноды под приложение:

[server]
port_rpc_admin_local
port_ws_admin_local
port_ws_public
port_peer

# admin — ТОЛЬКО localhost, наружу не открывать никогда
[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http

[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws

# публичный WebSocket для ваших приложений (приватный интерфейс,
# либо 127.0.0.1 + nginx с TLS спереди)
[port_ws_public]
port = 6005
ip = 0.0.0.0
protocol = ws
# лимит ресурсов на публичных клиентов:
# send_queue_limit = 500

# peer-протокол — вот его открываем в интернет
[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer

[node_size]
huge                     # medium при 32 ГБ RAM, huge при 64 ГБ+

[node_db]
type = NuDB              # NuDB для продакшен-нод (append-only, дружелюбен к SSD)
path = /var/lib/xrpld/db/nudb
online_delete = 512000   # хранить ~512k леджеров (~3-4 недели); минимум 256
advisory_delete = 0

[database_path]
/var/lib/xrpld/db

[ledger_history]
256                      # сколько леджеров догружать при старте; <= online_delete

[debug_logfile]
/var/log/xrpld/debug.log

[sntp_servers]
time.windows.com
time.apple.com
time.nist.gov
pool.ntp.org

[validators_file]
validators.txt

[ssl_verify]
1

Ключевые моменты:

network_id для mainnet не задаётся (он и есть значение по умолчанию). Ошибочно выставленный network_id — классический способ оказаться не в той сети.
UNL: штатный validators.txt указывает на dUNL-паблишеров (vl.ripple.com, unl.xrplf.org). Не редактируйте его без чёткого понимания зачем.
online_delete — то, что делает диск конечным: нода держит скользящее окно леджеров и удаляет старые. Диск считается под окно, а не наоборот.
Admin-порты наружу не открывать. admin = 127.0.0.1; если нужен удалённый API — публикуйте только port_ws_public за nginx с TLS (паттерн reverse-proxy с WebSocket upgrade-заголовками).
Firewall: входящий 51235/tcp открыт миру (peer-протоколу полезны входящие соединения), остальное закрыто или внутреннее.

Работа под systemd

sudo systemctl enable --now xrpld
sudo systemctl status xrpld

# логи
journalctl -u xrpld -f

Первый старт на mainnet: нода получает последний validated-леджер и догружает ledger_history. До "server_state": "full" — обычно 10–30 минут (на скромном железе дольше).

Проверка здоровья

/usr/bin/xrpld server_info | jq '.result.info | {build_version, server_state, complete_ledgers, peers, load_factor, amendment_blocked}'

Поле	Здоровое значение
`server_state`	`full` (у валидатора — `proposing`)
`complete_ledgers`	непрерывный диапазон, например `95000000-95120000`, не `empty`
`peers`	10+
`load_factor`	1 (всплески при fee escalation — норма)
`amendment_blocked`	должно отсутствовать — см. ниже

Обновление — и почему это не опционально

XRPL развивается через амендменты. Через две недели после того, как амендмент набирает >80% голосов валидаторов, он активируется во всей сети. Нода, чей бинарник не знает активированный амендмент, становится amendment-blocked: перестаёт отслеживать сеть, отказывается сабмитить транзакции, а в server_info появляется "amendment_blocked": true. Лечится только обновлением.

Практическая политика:

Подпишитесь на релизы rippled и блог XRPL; обновляйтесь в течение дней после релиза, а не месяцев
Дашборд голосования (xrpscan.com/amendments или команда feature) показывает очередь — всё, что выше 80%, это ваш таймер дедлайна

Процедура обновления (apt):

sudo apt update
sudo apt install --only-upgrade xrpld
sudo systemctl restart xrpld
watch -n 5 "/usr/bin/xrpld server_info | jq -r '.result.info.server_state'"

Даунтайм — минуты: после рестарта нода быстро ресинкается к текущему леджеру (историю не переигрывает). Конфиги апгрейд не перезаписывает; после мажорных версий сверьтесь с поставляемым примером (/etc/xrpld/xrpld.cfg.dpkg-dist, если есть).

Чтобы застраховаться от неожиданных мажорных апгрейдов — apt-mark hold xrpld и обновление вручную.

Подключение XrplCSharp

using Xrpl.Client;

// «голый» ws:// допустим ТОЛЬКО внутри доверенной приватной сети / localhost
IXrplClient client = new XrplClient("ws://10.0.0.5:6005");
// всё, что доступно снаружи, — только через TLS (nginx перед port_ws_public):
// IXrplClient client = new XrplClient("wss://xrpl-node.example.com");
await client.Connect();

ServerInfo info = await client.ServerInfo();
Console.WriteLine(info.Info.CompleteLedgers);

Рекомендации для продакшена с этим SDK:

Клиент — на публичный WS-порт своей ноды; admin-порты только для эксплуатации
Проверяйте, что complete_ledgers покрывает запрашиваемый диапазон — account_tx за пределами окна хранения вернёт неполные данные; за глубокой историей — full-history провайдер или Clio
SubmitAndWait опирается на LastLedgerSequence — его гарантии реальны только на здоровой синхронизированной ноде

Диагностика

Симптом	Причина	Решение
`"amendment_blocked": true`	Бинарник старее активированного амендмента	Немедленно обновить rippled
`server_state` застрял в `connected`/`syncing`	Слабый диск (IOPS), кривые часы, мало пиров	Только NVMe; проверить NTP (`[sntp_servers]`, `timedatectl`); открыть входящий 51235
`complete_ledgers: empty` при долгом аптайме	Нода постоянно теряет синк, история сбрасывается	То же — почти всегда IOPS диска или нехватка RAM
Диск растёт бесконечно	Не задан `online_delete`	Задать `online_delete` в `[node_db]` и перезапустить
`noCurrent` / `noNetwork` из API	Нода ещё не синхронизировалась или потеряла кворум	Дождаться `full`; проверить пиров и часы
Высокий `load_factor` на ваших запросах	Публичный порт перегружен или клиенты злоупотребляют	Rate-limit на nginx; масштабировать `node_size`/железо
Crash-loop после правки конфига	Синтаксическая ошибка или неизвестная секция для этой версии	`journalctl -u xrpld -n 50`; сверить с поставляемым примером конфига