Транзакції Lightning Network зависають на піку навантаження
Коли платіж у мережі Lightning не проходить за відведене вікно, рахунок у боті йде в тайм-аут — але не зникає. Користувач бачить «оплата не пройшла», тисне кнопку знову, а перша спроба в цей момент ще висить у маршруті.
Так і виникає lightning network завислий платіж: мережа тримає резерв під операцію, а інтерфейс уже пропонує повторити його.
Часто причина в нестачі ліквідності каналу. Баланси вхідної та вихідної сторони перекошені: учасник маршруту фізично не може провести платіж потрібного розміру, і він раз за разом іде в перебір обхідних шляхів замість швидкої відмови.
Чим більша сума й чим менший вільний запас на вузлі, тим вища ймовірність, що операція зависне або відпаде за часом.
Друга причина — розсинхрон статусів. Бот рахує стан за своїм таймером, мережа — за своїм, і поки перший чекає відповідь, платіж встигає пройти.
Повторне натискання «оплатити» призводить до повторного списання в боті, а баланс користувача розходиться з реальним станом мережі — звіряти доводиться вручну, за журналом операцій.
Додайте сюди тайм-аут платіжного рахунку, виставлений «із запасом»: користувач не розуміє, чекати йому чи платити знову, і вибирає друге. Тому оплата в телеграм-боті не проходить саме на піках — коли ліквідність розподіляється нерівномірно, а рахунки живуть довше звичайного. Далі розбираємо, як це закривається на рівні архітектури.
Що дає кастодіальна схема: швидкість і передбачуваність
Кастодіальна схема прибирає зі шляху платежу все, що залежить від чужих вузлів. Ключі й канали тримає сервіс, тому переказ між двома користувачами бота — це запис у внутрішньому реєстрі балансів: зарахування займає частки секунди, а не хвилини очікування підтвердження.
Розрахунок із мережею Lightning Network відходить на другий план і йде пакетно, вже після того, як людина побачила гроші на балансі.
Звідси другий ефект — частка успішних платежів. У публічній мережі переказ може не знайти маршрут із достатньою ліквідністю, і користувач отримує відмову на рівному місці.
Усередині сервісу маршрутів немає взагалі, а вихідні виплати йдуть нашими каналами, де ліквідність поповнюється заздалегідь, — успішність операцій утримується вище 99%.
Зникає цілий клас відмов — «завислий платіж», коли кошти заблоковані в чужому маршруті, статус невідомий, а підтримка розбирається вручну. Внутрішній переказ атомарний: або зарахування, або помилка до списання. Стану «в процесі» тривалістю в години в цій схемі просто не існує.
Час повернення до роботи рахується інакше. Стан каналів і реєстр відновлюються з останньої підписаної копії — без пересинхронізації з блокчейном і без ручного розбору завислих операцій. Після збою вузол знову приймає платежі за хвилини, а не за години.
Передбачуваність розрахунків — наслідок контролю: комісії та ліквідність під нашим управлінням, масові виплати йдуть за розкладом і не залежать від того, наскільки завантажена мережа в конкретний момент.
Lightning Network: режими зберігання коштів у боті
Режим зберігання визначає, хто відповідає за кошти при збої бота і наскільки дорогою є підтримка. Нижче — чотири схеми, між якими реально вибирають при запуску Lightning-платежів у боті, з їхніми обмеженнями.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Кастодіальний | Масові мікроплатежі та швидкий запуск: користувач не готовий сам тримати ключ | Довіра до оператора цілком; він же єдина точка відмови й об'єкт вимог щодо зберігання чужих коштів |
| Некастодіальний | Великі суми, коли користувач розпоряджається балансом сам | Відновлення доступу — турбота користувача, підтримка складніша, частина аудиторії відсіюється на вході |
| Гібридний | Обіг іде через бота, а резерв лежить у гаманці користувача | Подвійна логіка лімітів і переказів між контурами, складніша звірка та звітність |
| Зовнішній провайдер | Своєї інфраструктури немає, запуск потрібен без чергування | Залежність від лімітів і доступності провайдера, маршрутизація поза контролем, дані про платежі йдуть третій стороні |
Коли важливі контроль маршрутів і комісій, схему піднімають на своєму вузлі — але це вже експлуатація з моніторингом ліквідності каналів і чергуванням.
Ключі та доступ до коштів у будь-якому варіанті описуються політикою: хто в команді що може, як часто ротуються ключі, що відбувається при компрометації і як відновлюють доступ. Гібрид частіше беруть як компроміс — обіг тримають невеликим, а залишок не зберігають на стороні бота.
Етапи впровадження: від розбору сценаріїв до передачі
Стартовий етап — не код, а розбір того, як у продукті реально рухаються платежі: хто ініціює переказ, у який момент відповідальність переходить до кастодіального сервісу, що бачить користувач при обриві зв'язку між Telegram і вузлом.
Ці сценарії ми фіксуємо письмово, бо від них залежать і топологія каналів, і вимоги до журналу операцій, і глибина перевірки на збої.
- Аудит платіжних сценаріїв. Збираємо всі вітки: вхідні та вихідні перекази, повернення, недоплати, повторні спроби після закінчення рахунку. На виході — перелік станів бота і правила переходів між ними.
- Схема руху коштів. Описуємо, як внутрішній баланс користувача співвідноситься із залишком на вузлі, де зберігаються ключі і в який момент операція вважається завершеною. Ця схема стає основою облікової логіки та реєстру операцій.
- Налаштування каналів і ліквідності. Визначаємо число каналів, їхній розподіл за напрямками та пороги автоматичної ребалансировки, щоб вхідна ємність не закінчувалася в пікові години.
- Перевірка на відмовостійкість. Проганяємо втрати вузла, недоступність провайдера і застарілий стан: відновлення з резервної копії, коректне закриття каналів, обробку завислих платежів без подвійного зарахування.
- Звірка та моніторинг. Автоматизуємо зіставлення внутрішнього реєстру зі станом вузла і виводимо алерти на розбіжність, нестачу ємності та зростання черги неуспішних операцій.
- Передача та навчання підтримки. Віддаємо конфігурації, схеми, інструкції щодо типових інцидентів і проводимо навчання першої лінії: як читати статуси, що ескалувати і які дії безпечні без інженера.
Що залишається у вас: конфігурації, схеми, регламенти
Передаємо не доступ до бота, а комплект, за яким інфраструктуру можна підняти й супроводжувати своєю командою. Усе лежить у закритому сховищі з історією правок: видно, хто і коли змінював параметри Lightning-вузла, ліміти та правила маршрутизації.
- Конфігурація бота — файли налаштувань вузла і сервісу, ліміти на разовий платіж і добовий обіг за користувачем, правила вибору маршруту та розмір комісії.
- Схема потоків коштів — діаграма руху коштів між гаманцями, каналами та резервом, із межею кастодіального контуру та переліком ключів.
- Політики доступу та ролі — матриця: хто виводить кошти, хто лише дивиться, хто змінює конфігурацію; друге підтвердження на критичні операції.
- Регламент реагування на збій — що перевіряємо при недоступності вузла, розриві каналу або завислій транзакції, що перезапускаємо і коли ескалуємо.
- Документація щодо схеми — опис архітектури, точок відмови та порядку відновлення з резервної копії з перевіреним часом розгортання.
- Моніторинг і оповіщення — пороги за балансом каналів, затримкою платежів і часткою помилок; повідомлення йдуть у черговий канал, а не в особисті повідомлення інженеру.
Закінчуємо передавальною сесією: ваша команда відтворює відновлення вузла на тестовому контурі своїми руками і далі веде супровід самостійно.
Кейс: бот підписок зі зростанням платежів без обривів каналів
Що було до переведення
Бот підписок обслуговував кілька тисяч продовжень на добу, і кожен платіж ішов через окремий канал зі своїм балансом.
На піках ліквідність розповзалася: частка успішних платежів падала до 62%, інвойси завершувалися, частина каналів опинялася в стані, де платіж не проходить ні в один бік.
Повторні списання не були ідемпотентними — при тайм-ауті продовження йшло другим інвойсом, і повернення розбирали вручну.
Що змінили
Зібрали кастодіальну схему: єдиний пул керованих каналів і ребалансировка за розкладом, плюс тригер при просіданні локального балансу нижче порогу. Кожне продовження отримало фіксований ідентифікатор — повторна спроба повертає результат першої, а не створює нове списання.
На піках продовження йдуть через чергу з обмеженням паралелізму, щоб потік не виїдав ліквідність одного вузла.
Метрики до і після
- Частка успішних платежів: 62% → 96% у звичайні дні та не нижче 94% при чотириразовому піковому навантаженні.
- Повторні списання: 1,8% → 0,02% від числа продовжень.
- Відновлення після відмови вузла: з 40 хвилин ручних перемикань до 3 хвилин автоматичного переведення на резервний.
Схема працює на Lightning Network; відмовостійкість тримається на автоматиці, а не на черговому інженері, — тому зростання числа підписників більше не впирається в ручні розбори.
Що робити, якщо бот уже працює і потрібен прийом оплати
Працюючий бот — це постійний потік запитів і жива база, тому доопрацювання наявного бота починається не з правки коду, а з розділення контурів: новий прийом платежів піднімається поруч із бойовим і пише в ті самі таблиці, а поточні сценарії продовжують обслуговуватися.
Додавання оплати в бота не потребує паузи — старі обробники залишаються увімкненими, поки нові проходять перевірку на реальних операціях обмеженого обсягу.
Змінюється лише шар підтвердження: замість ручної звірки з'являється вузол Lightning Network із каналами, вхідною ліквідністю та прив'язкою підтвердження до конкретного рахунку.
Логіка самого бота — команди, ролі, меню, видача доступу — залишається незмінною, бо вона не знає, звідки прийшло підтвердження.
Міграція без зупинки сервісу йде етапами: спочатку розширення схеми зі зворотною сумісністю (нові поля необов'язкові, старий код їх ігнорує), потім тіньовий режим, коли оплата приймається, але зарахування звіряється з поточним механізмом, і лише після збігу — перемикання. Відкат — одне налаштування, що повертає попередній шлях підтвердження.
Сумісність із поточною базою впирається в одне питання: чи є у вас внутрішній ідентифікатор користувача, що не залежить від месенджера.
Якщо так, платіж пов'язується з ним напряму, а журнал операцій, куди записи лише додаються, закриває звірку та розбір розбіжностей запитом замість читання логів.
Окремо проєктуємо кастодіальну частину: де лежать ключі, хто ініціює повернення, що відбувається при нестачі вхідної ліквідності і як бот поводиться при недоступності вузла.
Ці сценарії перевіряються до включення прийому — інакше перший збій станеться рівно на першій же великій операції.
Технічні питання: ліквідність, ключі, відмовостійкість
Технічні сумніви навколо кастодіального бота в Lightning Network зводяться до межі відповідальності: що контролює сервіс, а що залишається на боці користувача. Нижче — відповіді на питання, які найчастіше спливають до початку розробки.
Хто відповідає за кошти користувачів?
Ключі вузла під контролем сервісу — отже, відповідальність за кошти на ньому. Облік операцій ведеться окремо від стану каналів, баланси звіряються автоматично, розбіжність блокує виведення до розбору.
Як захищені ключі?
Основна маса коштів лежить поза гарячим контуром, вузол працює з обмеженим операційним залишком. Ключі не покидають захищене середовище, доступ розмежований за ролями та логується.
Що відбувається при перезапуску вузла?
Стан каналів фіксується на диску, після старту вузол відновлює з'єднання і досинхронізується. Платежі на цей час стають у чергу і йдуть після підйому, дублі виключені за ідентифікатором операції.
Що робити при нестачі ліквідності?
Вхідна та вихідна ліквідність розподіляється за каналами; при перекосі запускається ребалансировка або відкриваються нові. Пороги попереджають заздалегідь, частина платежів іде резервним маршрутом.
Чи можна змінити модель зберігання?
Перехід до самостійного зберігання ключів користувачем можливий, але це переробка обліку, видачі ключів і міграції активних каналів — плануємо окремим етапом.
Обговоримо задачу: розберемо схему і повернемося з оцінкою
Щоб повернутися з оцінкою і планом робіт, а не з приблизною вилкою «плюс-мінус», нам потрібні вхідні дані від замовника. Розбір починається зі сценаріїв оплати: хто поповнює баланс, що відбувається при обриві зв'язку і як бот має поводитися в цей момент.
За цими відповідями видно, які частини кастодіальної схеми лягають на сервер, а які залишаються на боці вузла Lightning Network.
Що підготувати до розмови:
- Сценарії оплати: прийом, виплата, переказ між мережами, розбиття великої суми на частини.
- Обсяги: пікове навантаження, добове число операцій, очікуване зростання, середній і максимальний платіж.
- Вимоги до повернень: терміни, часткове повернення, спірні операції, ручне підтвердження адміністратором.
- Ролі доступу: хто бачить баланс, хто ініціює виплату, чи потрібні підтвердження другої особи, як ведеться журнал дій.
- Обмеження щодо підтримки: режим роботи, допустимий час простою, хто на боці замовника реагує на збої.
- Порядок передачі проєкту: вихідники, схема інфраструктури, інструкції для чергового, навчання команди.
- Поточна інфраструктура: свій вузол чи сторонній, які інтеграції з обліком і звітністю обов'язкові.
Далі збираємо схему й оцінюємо трудовитрати за етапами. Якщо частина даних поки невідома, фіксуємо припущення і перевіряємо їх на першому кроці — так вимоги до повернень і порядок передачі проєкту не спливуть сюрпризом у середині роботи. Опишіть задачу в зручному вигляді, і ми повернемося з планом.
