дата публікації

Чому XRP Ledger сповільнився: колишній CTO Ripple Шварц деталізує основні недоліки

джерело

На мережі $XRP Ledger (XRPL) стався технічний збій, який сповільнив обробку транзакцій, що призвело до відкритого аналізу архітектури протоколу.

Девід Шварц, колишній технічний директор Ripple і співавтор системи, публічно вказав на вразливі місця блокчейну, які були виявлені під час інциденту. Проблеми почалися, коли команда $XRP Ledger Operations зафіксувала аномалію: книги мережі почали закриватися значно повільніше, ніж зазвичай.

Поки інженери шукали причину затримок, у спільноті виникли запитання щодо надійності децентралізованої системи.

Користувачі переживали про можливість відмови мережі через перевантаження кількох ключових вузлів.

Шварц увійшов у дискусію, щоб пояснити реальні межі стійкості XRPL. За його оцінкою, програмне забезпечення $XRP Ledger захищене багаторівневою системою безпеки, проте в теорії є лише два сценарії, які здатні повністю паралізувати мережу: 1.

Масове збої в інфраструктурі: ситуація, коли велика кількість серверів-валідаторів у всьому світі виходить із ладу одночасно, що можливо лише в разі глобальної катастрофи. 2.

Збій алгоритму консенсусу: помилка у механізмі досягнення угоди між вузлами або відмова іншої базової функції протоколу на рівні коду. Затримка раундів є прямим доказом того, що технологічні запасі мережі зменшилися.

Шварц вказав, що це вказує на те, що мережу або атакують, або в коді активувалася прихована помилка. Водночас архітектор спростував чутки про вразливість блокчейну до єдиних точок відмови.

Мережа повністю децентралізована, тому вимкнення або перевантаження навіть великого вузла (включно з його власним) не впливає на загальну працездатність XRPL. Основною практичною проблемою стала вразливість систем моніторингу мережі під час пікових навантажень.

Коли раунди консенсусу сповільнилися, валідатори різко переключилися на максимальне навантаження.

Власний вузол Шварца не витримав напливу запитів, що призвело до зависання локальних RPC-з'єднань у стані CLOSE_WAIT. Через це зависання внутрішня система моніторингу Шварца не змогла зафіксувати та передати діагностичні дані у найкритичніший момент.

В результаті інженер змушений був перезавантажити сервер без точного розуміння причини збою. Під час обговорення з'ясувалося, що вузол співавтора XRPL надсилав логи на застарілий тестовий хост Фонду $XRP Ledger (XRPLF). Наразі команда інженерів та операторів спільноти вручну аналізує збережені логи, щоб виявити та повністю усунути дефект.

Шварц резюмував, що, незважаючи на тимчасове зниження запасів безпеки, команда не має причин для паніки.

Розробники повністю контролюють ситуацію, а архітектура коду має достатній технологічний резерв для підтримання працездатності мережі.