Після уповільнення в XRPL Девід Шварц пояснив ризики мережі

Технічний збій, що призвів до уповільнення транзакцій у мережі XRP Ledger, викликав більш широке дослідження архітектури протоколу. Девід Шварц, колишній технічний директор Ripple та один із розробників системи, у своїй публічній оцінці після інциденту розповів про основні вразливі місця мережі.

Уповільнені закриття реєстрів призвели до початку розслідування

Проблема виникла, коли команда XRP Ledger Operations зафіксувала аномалію в мережі. Помітно уповільнене закриття реєстрів на мережі спонукало інженерів дослідити джерело затримки. У цьому процесі також виникли питання щодо стійкості децентралізованої структури в спільноті.

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

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

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

Відповідь на твердження про єдину точку помилки

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

Ripple, одна з провідних компаній в екосистемі XRP, розробляє платіжні інфраструктури та фінансові рішення на основі блокчейну. XRP Ledger відомий як відкритий блокчейн, що працює незалежно від Ripple.

Системи моніторингу зазнали збою під навантаженням

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

Міні-словник: RPC - це метод зв'язку, який дозволяє програмному забезпеченню запитувати дані з іншої системи та виконувати команди. CLOSE_WAIT - це стан, коли з'єднання отримало сигнал закриття з іншого боку, але процес на місцевій стороні ще не завершено.

Через це зависання внутрішня система моніторингу Шварца не змогла зафіксувати та передати діагностичні дані в найкритичніший момент. Інженер змушений був перезапустити сервер, не з'ясувавши точної причини збою.

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

Розглядаються записи старого тестового сервера

Під час розслідування також з'ясувалося, що журнал записів, що належить одному з розробників XRPL, був надісланий на стару тестову машину XRP Ledger Foundation. Це ще більше ускладнило повне збирання даних під час інциденту.

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