XRP Ledger выпустила версию xrpld 3.2.1 — рабочее горячее исправление, направленное на остановку флудинга манифестов валидаторов, который создал нагрузку на часть peer-to-peer инфраструктуры сети 31 июля 2026 года. xrpld — это эталонное серверное ПО, которое участники запускают для работы узлов и валидаторов в сети XRPL. Блокчейн продолжал закрывать реестры без перерывов, подтверждая, что консенсус оставался полностью рабочим, даже когда отдельные узлы испытывали аномальные нагрузки данных.

XRP Ledger Operations анонсировала релиз через свой официальный аккаунт в X:

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

Администраторам узлов было поручено безотлагательно установить горячее исправление и выполнить второй перезапуск вскоре после первоначальной установки. Обновлённая сборка вводит механизмы контроля, предотвращающие потребление недоверенными данными валидаторов непропорциональных объёмов памяти, пропускной способности, хранилища и вычислительных ресурсов.

Как флудинг манифестов создал нагрузку на peer-инфраструктуру XRPL

XRPL опирается на набор валидаторов, которых каждый оператор определяет как доверенные через Unique Node List (UNL). В консенсусном принятии решений узла участвуют только валидаторы из его UNL. Манифесты валидаторов связывают постоянную мастер-личность валидатора с временным ключом подписи, используемым во время раундов консенсуса. Эта архитектура позволяет операторам периодически менять рабочие ключи, сохраняя мастер-учётные данные в офлайне и поддерживая установленную сетевую идентичность валидатора.

Предыдущие версии xrpld не имели ограничения на количество манифестов, связанных с неизвестными ключами валидаторов, которые узел мог принимать, хранить и ретранслировать. Поскольку каждый узел передаёт данные манифестов подключённым к нему пирам независимо от статуса доверия, избыточные недоверенные данные распространялись по сети и накапливались в локальных кэшах.

Инцидент затронул распространение сообщений на peer-уровне, а не балансы счетов, отдельные транзакции или правила валидации реестра. Это различие имеет принципиальное значение для архитектуры блокчейна в целом: сбои на уровне консенсуса могут остановить цепь, тогда как сбои на peer-уровне ухудшают связность без нарушения целостности реестра. Хотя XRPL продолжал обрабатывать транзакции и закрывать реестры по расписанию, нагрузка на peer-соединения ухудшила связность и замедлила распространение информации по сети.

Четыре защитных механизма в версии 3.2.1

Версия 3.2.1 содержит шесть коммитов, охватывающих 13 файлов. Изменения реализуют механизмы контроля в четырёх критических точках, где чрезмерный или повторяющийся трафик манифестов мог создать нагрузку на узел:

1. Отклонение по размеру до декодирования. xrpld теперь отклоняет отдельные манифесты, превышающие ожидаемый размер кодирования, до начала процесса декодирования, предотвращая запуск избыточных вычислительных операций слишком большими входными данными.

2. Отбрасывание недоверенных пакетов. Узлы теперь отбрасывают входящие пакеты, содержащие чрезмерное количество недоверенных манифестов. При этом ПО не отключает автоматически устаревшие узлы, передающие слишком большие пакеты, что снижает риск фрагментации сети в период обновления.

3. Ограничение приветственных сообщений. Горячее исправление ограничивает массовое приветственное сообщение манифестов, которым обмениваются два узла при установке нового peer-соединения. Доверенные записи остаются полностью доступными, тогда как недоверенная передача сокращается как на стороне отправки, так и на стороне приёма.

4. Лимит хранения для неизвестных ключей. Каждый узел может хранить не более 100 манифестов, привязанных к неизвестным ключам валидаторов. После достижения этого предела дополнительные записи отклоняются, а недоверенные манифесты больше не сохраняются на диск.

Обязательный второй перезапуск и проверка ключа подписи

После установки обновления администраторам было указано подождать примерно одну–две минуты и убедиться, что xrpld остался в рабочем состоянии. Полная синхронизация не требуется перед переходом к следующему шагу.

После подтверждения, что обновлённый сервис работает, операторы должны перезапустить xrpld второй раз. Команда охарактеризовала этот второй перезапуск как неотъемлемый завершающий этап процедуры обновления.

Администраторам, использующим пакетные установки, также следует проверить текущий ключ подписи ПО Ripple. Ripple сменила GPG-ключ, используемый для подписи пакетов xrpld, в феврале 2026 года, а это означает, что системы, ещё не доверяющие новому ключу, могут не получать автоматические обновления.

Горячее исправление не вводит сетевых поправок и не изменяет правила обработки транзакций. Вместо этого оно устанавливает жёсткие границы для недоверенных peer-данных на каждом этапе — перед декодированием, ретрансляцией, кэшированием или постоянным хранением. Ограничив размер манифестов, объём пакетов, приветственные сообщения и хранение для неизвестных ключей, XRP Ledger закрыла четыре пути эксплуатации, использованные при флудинге 31 июля. Инцидент показал, что злоупотребления на peer-уровне могут создавать нагрузку на отдельные серверы даже тогда, когда консенсус продолжает функционировать в обычном режиме — это класс уязвимостей, который другие блокчейн-сети также устраняли посредством укрепления peer-протоколов.

Ожидается, что полный разбор инцидента будет предоставлен сообществу.