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

Я багато років працюю у криптосфері і бачив надто багато вибухів ланцюга, спричинених дрібними помилками в коді. Драма «автоматизованого збою», розгорнутої в реєстрі XRP минулої ночі, перетворилася на класичний випадок: автоматизована система провідного постачальника послуг кастодіанів досі лихоманково створює нові рахунки партіями після того, як баланс XRP у відповідному гаманці спорожнений. Всього за кілька годин у мережу XRP було надіслано майже 11 000 недійсних запитів на транзакції.

Це не якийсь хак. Говорячи прямо, скрипт автоматизації повністю вийшов з-під контролю.

**Від нормального потоку до нескінченних петель**

Все просто. Скрипт створення акаунта кастодіана генерує XRP-гаманці для користувачів відповідно до встановленої логіки, і система спочатку працювала досить стабільно. Проблема застрягла в одному зв'язку: логіці суджень після того, як баланс буде очищено.

Реєстр XRP розроблений із механізмом — кожен новий рахунок повинен заблокувати щонайменше 20 XRP як резерв, і 4 з 10 000 XRP будуть витрачені на одну транзакцію. Цей трюк полягає в тому, щоб запобігти тому, щоб погані хлопці створювали спам-акаунти пакетами та паралізували мережу.

Теоретично, коли XRP-баланс кастодіана вичерпається, скрипт слід зупинити. Але яка ж реальність? Система застрягла в мертвому циклі. Він не припинився, але продовжував надсилати запити на створення з високою частотою.

Цей автоматичний випадок відриву перетворив сам «захисний механізм» на джерело стресу. Він нагадує всім просту істину: яким би розумним не був код, він повинен мати відповідні запобіжники та механізми людського втручання. Незалежно від того, наскільки надійний головний хост, якщо в проєктуванні автоматизації є прогалина, наслідки можуть вплинути на весь публічний ланцюг.