9 октября 2026 года XRPL опубликовал сведения о двух ошибках, уже исправленных в xrpld 3.4.1: переполнении платёжного механизма и пробеле проверки Batch. Исправления включались разными способами. Оператору нужно разделять версию сервера и состояние amendment. Обычному держателю не следует принимать дату раскрытия за новый срок миграции кошелька.
Разделите выпуск, раскрытие и активацию
В уведомлении о 3.4.1 операторов призвали обновиться и указали ожидаемую октябрьскую активацию исправления Batch. Более поздний отчёт о раскрытии датирует выпуск 25 сентября и фиксирует активацию fixBatchV1_2 вместе с BatchV1_1 9 октября. Исправление переполнения, напротив, начинало действовать на каждом сервере после обновления самого сервера.
Авторы отчёта не нашли доказательств эксплуатации переполнения в публичной сети; проблему Batch описали как исправленную до активации затронутой функции в mainnet. Эти сведения нужно атрибутировать отчёту. Они не являются проверкой личного аккаунта или гарантией по другим инцидентам. Для диагностики собственного ПО и состояния сервиса не требуется воспроизводить атаку или собирать вредоносную транзакцию.
Проверьте сервер, к которому обращается приложение
Версия установленного пакета полезна, но сама по себе не определяет работающий процесс, старый контейнер или другой сервер за балансировщиком. Установите, кто обработал запрос приложения. Если точек доступа несколько, результат одной не подтверждает версии остальных. Номер самого кошелька также относится к иному компоненту, чем сервер, который кошелёк использует для запросов.
В официальном справочнике server_info для xrpld описаны поля работающей сборки и состояния сервера, необязательный признак блокировки по amendments и сведения подтверждённого реестра. Используйте определения, а не устаревшие условные значения примера из документации. Этот материал не выполняет запросов к работающему узлу и не публикует частную конфигурацию оператора.
| Что сохранить | На какой вопрос отвечает | Чего отдельно не доказывает |
|---|---|---|
| Точку доступа и время проверки | Какой сервис проверен и когда? | Состояние всех серверов за ним и будущих запросов |
| build_version | Какую версию сообщает работающий xrpld? | Обновление каждой зависимости приложения |
| amendment_blocked, если присутствует | Сообщает ли узел о блокировке по amendments? | Отсутствие любых других проблем сервиса |
| server_state и validated_ledger | Какие состояние и сведения подтверждённого реестра сообщает узел? | Внутреннее зачисление аккаунта клиента |
| Запись обновления оператора | Какое контролируемое изменение внедрения сделано? | Успех каждой последующей транзакции |
Голосование не заменяет установленное исправление
Практическая разница заключается в способе включения правил. Для непосредственного исправления сервера должно работать исправленное ПО. Amendment дополнительно проходит порядок активации. Если считать оба случая одним голосованием на панели, можно не проверить нужный компонент. С другой стороны, установка пакета сама по себе не показывает активированные правила той сети, которую использует сервис.
Условный администратор обновил пакет на хосте, а платёжное приложение продолжило обращаться к старому контейнеру. Заявка сопровождения уже закрыта, хотя нужный сервер не изменился. Здесь требуется сверить точку доступа, работающую версию и запись внедрения. Перевод клиентских остатков в новый кошелёк не решает такую задачу. Доказательство обновления должно относиться к реально обслуживающему приложению компоненту.
- Определите, управляете ли xrpld сами или зависите от поставщика; запишите нужную точку доступа без учётных секретов.
- Сопоставьте работающую версию с текущими рекомендациями проекта, включая исправления из 3.4.1.
- Проверьте сообщаемое состояние сервера и amendments по документации соответствующего типа узла.
- После обновления проверьте фактический сервер приложения и обычную разрешённую операцию; сохраните результаты с записью обслуживания.
Держателю нужно установить этап платежа
Раскрытие ошибки реализации узла не устанавливает компрометацию определённого кошелька. Если не пришёл платёж или депозит, сохраните идентификатор транзакции, подтверждённый результат и номер операции принимающего сервиса. Так поддержка сможет отличить проблему серверной зависимости от внутреннего зачисления. Новый платёж не следует повторно отправлять лишь потому, что появилась новость об уязвимости. Сначала требуется понять состояние исходного действия.
Для обмена проверьте поддерживаемые монеты и сети, прочитайте порядок заявки и используйте доступное направление простого обмена. Условия AML KOT.CASH относятся к отдельной части исполнения. Эти страницы не заявляют аудит XRPL, не подтверждают обновление узла и не гарантируют завершение определённого пополнения.
Частые вопросы
Новость об обновлении XRP Ledger показывает версию моего сервера?
Нужна точка доступа и сведения реально работающего компонента. Публикация релиза и установленный пакет не определяют все серверы приложения.
Исправления обновления XRP Ledger включались одним голосованием?
В отчёте различаются непосредственное исправление переполнения на сервере и активация amendment для Batch. Проверяется механизм конкретного изменения.
Что оператору узла XRP Ledger записать после обновления?
Сохраните точку доступа, работающую сборку, состояние и нужные сведения amendments вместе с записью внедрения. Проверяйте реальную зависимость приложения, а не только закрытую заявку обслуживания.