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