Нещодавно поданий звіт про помилку показує, що 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 досягає згоди щодо кожного нового реєстру. Пропозиції вузла мають вагу лише тоді, коли інші сервери довіряють його ключу через власні списки унікальних вузлів, тож застаріла чи невідповідна ідентичність може заплутати тих, хто перевіряє машину. Заплутані логи можуть уповільнити формування такої довіри.
Поки що невідповідність не спричинила відмови в роботі мережі. Водночас вона продовжує низку дефектів, які розробники вже позначили від часу релізу в середині місяця — від збоїв синхронізації до крашу парсера конфігурацій.
Репортер запропонував виправлення: змусити сервісні логи виводити саме той ключ, яким реально користується сервер, або показувати разом похідний і активний ключі. На звіт ще не призначено мейнтейнера. Деякі раніше подані питання вже підтверджено як баги й поставлено в чергу на рев’ю, тоді як інші лишаються відкритими, поки контриб’ютори їх оцінюють.
Впровадження відстає, поки триває голосування за amendment
Впровадження релізу йде повільно. Близько 30% вузлів нині працюють на версії 3.2.0, тоді як більшість операторів, за публічними даними мережі, залишаються на попередній збірці 3.1.3.
Розгортання стартувало 15 червня, коли оновлення перейменувало основне програмне забезпечення з rippled на xrpld і пообіцяло економію пам’яті на 30–40%. Відтоді оператори повідомляли про збої синхронізації, помилки розрахунку ретрансляцій і тепер — про невідповідність ключів у свіжій збірці, причому жодного патчу досі не випущено. Ті, хто зволікає з оновленням, також ризикують опинитися в стані блокування через amendment, щойно валідатори ратифікують fixCleanup3_2_0 — зміну‑очистку, яку Ripple вже підтримала в поточному голосуванні.
Читайте далі: Mane City Mobile виходить на iOS та Android у 100+ країнах