В недавно поданном отчёте об ошибке показано, что программное обеспечение XRP Ledger версии v3.2.0 логирует один ключ валидатора, а фактически запускает другой, тогда как примерно 30% нод уже перешли на переименованный сервер.
Ключевые моменты:
- Оператор ноды сообщил, что v3.2.0 записывает в лог новый ключ мигрировавшего валидатора, в то время как сервер продолжает работать со старым.
- Ошибка проявляется на Ubuntu 22.04, когда существующий токен валидатора добавляется на уже запущенный RPC‑узел.
- Доля обновившихся до новой версии узлов составляет около 30%, большинство операторов остаются на предыдущей сборке.
Баг в XRP Ledger выявляет несоответствие ключей
Дефект, зарегистрированный под номером #7581 в трекере GitHub проекта, проявляется после того, как оператор переносит существующий валидатор на уже работающий RPC‑узел и затем перезапускает сервис. В логах сервиса отображается новая идентичность мигрировавшего валидатора, тогда как endpoint server_info продолжает возвращать старый ключ, который хранится в локальном файле wallet.db. Эти две записи перестают совпадать.
Воспроизвести расхождение несложно. По словам оператора, добавление существующего токена валидатора на активную ноду и перезапуск сервера запускают проблему на Ubuntu 22.04 — это типичный сценарий при рутинных миграциях.
Также читайте: Продажа Anthropic Perp: предупреждение для крипто‑ставок до IPO?
Идентичность валидатора — основа консенсуса сети
Идентичность валидатора находится в центре механизма согласования каждого нового реестра XRP Ledger. Предложения ноды имеют вес только тогда, когда другие серверы доверяют её ключу через свои списки уникальных узлов (UNL), поэтому устаревшая или несогласованная идентичность может запутать любого, кто анализирует конкретную машину. Некорректные логи могут замедлить формирование этого доверия.
Пока несоответствие не привело к отключениям или простою. Тем не менее, оно удлиняет цепочку дефектов, которые разработчики уже отмечали с момента релиза в середине месяца — от сбоев синхронизации до падения парсера конфигурации.
Сообщивший об ошибке предложил исправление: сделать так, чтобы в логах сервиса печатался ключ, который сервер действительно использует, либо одновременно показывались и производный, и активный ключ. К отчёту ещё не прикреплён ответственный мейнтейнер. Ряд более ранних обращений уже подтверждены как ошибки и поставлены в очередь на рассмотрение, тогда как другие остаются открытыми, пока участники обсуждают их.
Отставание в обновлении на фоне голосования по поправке
Внедрение релиза идёт медленно. Около 30% узлов сейчас запускают версию 3.2.0, тогда как большинство операторов остаются на предыдущей сборке 3.1.3, согласно открытым данным о сети.
Развёртывание началось 15 июня, когда обновление переименовало основное ПО с rippled на xrpld и пообещало сокращение потребления памяти на 30–40%. С тех пор операторы сообщали о разрывах синхронизации, неверных расчётах при ретрансляции и теперь — о несоответствии ключей в новой сборке, при этом патч пока не выпущен. Отстающие по обновлению также рискуют перейти в состояние блокировки из‑за поправки, когда валидаторы ратифицируют fixCleanup3_2_0 — корректирующее изменение, которое Ripple уже поддержала в текущем голосовании.
Читайте далее: Mane City Mobile выходит на iOS и Android в более чем 100 странах