Технічний збій у мережі XRP Ledger (XRPL), який уповільнив обробку транзакцій, перетворився на відкритий аналіз архітектури протоколу. Девід Шварц, колишній головний технічний директор Ripple і співтворець системи, публічно назвав уразливі місця блокчейну, які виявив цей інцидент.
Проблеми почалися після того, як команда XRP Ledger Operations зафіксувала аномалію: реєстри мережі почали закриватися значно повільніше, ніж зазвичай. Поки інженери шукали причину затримок, у спільноті виникли питання щодо надійності децентралізованої системи. Користувачі турбувалися, чи може мережа вийти з ладу через перевантаження кількох ключових вузлів. Шварц долучився до обговорення, щоб пояснити реальні межі стійкості XRPL.
За оцінкою Шварца, програмне забезпечення XRP Ledger захищене багаторівневою системою безпеки. Тим не менш, теоретично існують лише два сценарії, здатні повністю паралізувати всю мережу:
Масова відмова інфраструктури: ситуація, коли величезна кількість серверів валідаторів по всьому світу виходить з ладу одночасно. Такий результат можливий лише у разі глобальної природної катастрофи, тому розробники вважають його малоймовірним.
Збій алгоритму консенсусу: помилка в самому механізмі досягнення згоди між вузлами або відмова іншої базової функції протоколу на рівні коду.
Зафіксоване уповільнення раундів є прямим свідченням того, що технологічні запаси міцності системи зменшилися. Шварц визнав, що це маркер того, що мережа або зазнає цілеспрямованої атаки, або всередині коду активувався прихований баг.
Водночас архітектор спростував чутки про вразливість блокчейну до єдиних точок відмови. Мережа повністю децентралізована, тому вимкнення або перевантаження навіть великого вузла (включно з його власним вузлом) не впливає на загальну працездатність XRPL та час безперебійної роботи.
Як творець мережі залишився без логів
Головною практичною проблемою виявилася вразливість систем моніторингу мережі під час пікових навантажень. Коли раунди консенсусу уповільнилися, валідатори різко перейшли на максимальне навантаження. Власний вузол Шварца не витримав напливу запитів, через що локальні RPC-з'єднання зависли в стані CLOSE_WAIT.
Через це зависання внутрішня система моніторингу Шварца не змогла зафіксувати та передати діагностичні дані в найкритичніший момент. Як наслідок, інженеру довелося перезавантажити сервер, не розуміючи точної причини збою.
Під час обговорення з'ясувалося, що вузол співтворця XRPL надсилав логи на застарілий тестовий хост XRP Ledger Foundation (XRPLF).
Наразі команда інженерів і операторів спільноти вручну аналізує збережені логи, щоб ізолювати та повністю усунути дефект. Шварц підсумував, що, попри тимчасове зменшення запасів міцності, у команди немає причин для паніки. Розробники повністю контролюють ситуацію, а архітектура коду має достатній технологічний резерв, щоб підтримувати працездатність мережі.
