Lightning-бот для Telegram: кастодиальная архитектура

Транзакции Lightning Network зависают на пике нагрузки

Когда платёж в сети Lightning не проходит за отведённое окно, счёт в боте уходит в таймаут — но не исчезает. Пользователь видит «оплата не прошла», жмёт кнопку снова, а первая попытка в этот момент ещё висит в маршруте. Так и возникает lightning network зависший платёж: сеть держит резерв под операцию, а интерфейс уже предлагает повторить её.

Чаще всего дело в нехватке ликвидности канала. Балансы входящей и исходящей стороны перекошены: участник маршрута физически не может провести платёж нужного размера, и он раз за разом уходит в перебор обходных путей вместо быстрого отказа. Чем крупнее сумма и чем меньше свободный запас на узле, тем выше шанс, что операция зависнет или отвалится по времени.

Вторая причина — рассинхрон статусов. Бот считает состояние по своему таймеру, сеть — по своему, и пока первый ждёт ответ, платёж успевает пройти. Повторное нажатие «оплатить» приводит к повторному списанию в боте, а баланс пользователя расходится с реальным состоянием сети — сверять приходится вручную, по журналу операций.

Добавьте сюда таймаут платёжного счёта, выставленный «с запасом»: пользователь не понимает, ждать ему или платить заново, и выбирает второе. Поэтому оплата в телеграм-боте не проходит именно на пиках — когда ликвидность распределяется неравномерно, а счета живут дольше обычного. Дальше разбираем, как это закрывается на уровне архитектуры.

Что даёт кастодиальная схема: скорость и предсказуемость

Кастодиальная схема убирает из пути платежа всё, что зависит от чужих узлов. Ключи и каналы держит сервис, поэтому перевод между двумя пользователями бота — это запись во внутреннем реестре балансов: зачисление занимает доли секунды, а не минуты ожидания подтверждения. Расчёт с сетью Lightning Network уходит на второй план и идёт пакетно, уже после того, как человек увидел деньги на балансе.

Отсюда второй эффект — доля успешных платежей. В публичной сети перевод может не найти маршрут с достаточной ликвидностью, и пользователь получает отказ на ровном месте. Внутри сервиса маршрутов нет вовсе, а исходящие выплаты идут по нашим каналам, где ликвидность пополняется заранее, — успешность операций удерживается выше 99%.

Исчезает целый класс отказов — «зависший платёж», когда средства заблокированы в чужом маршруте, статус неизвестен, а поддержка разбирается вручную. Внутренний перевод атомарен: либо зачисление, либо ошибка до списания. Состояния «в процессе» длиной в часы в этой схеме просто не существует.

Время возврата в строй считается иначе. Состояние каналов и реестр восстанавливаются из последней подписанной копии — без пересинхронизации с блокчейном и без ручного разбора повисших операций. После сбоя узел снова принимает платежи за минуты, а не за часы.

Предсказуемость расчётов — следствие контроля: комиссии и ликвидность под нашим управлением, массовые выплаты идут по расписанию и не зависят от того, насколько загружена сеть в конкретный момент.

Lightning Network: режимы хранения средств в боте

Режим хранения определяет, кто отвечает за средства при сбое бота, и насколько дорого обходится поддержка. Ниже — четыре схемы, между которыми реально выбирают при запуске Lightning-платежей в боте, с их ограничениями.

Когда важны контроль маршрутов и комиссий, схему поднимают на своём узле — но это уже эксплуатация с мониторингом ликвидности каналов и дежурством. Ключи и доступ к средствам в любом варианте описываются политикой: кто в команде что может, как часто ротируются ключи, что происходит при компрометации и как восстанавливают доступ. Гибрид чаще берут как компромисс — оборот держат небольшим, а остаток не хранят на стороне бота.

Этапы внедрения: от разбора сценариев до передачи

Стартовый этап — не код, а разбор того, как в продукте реально двигаются платежи: кто инициирует перевод, в какой момент ответственность переходит к кастодиальному сервису, что видит пользователь при обрыве связи между Telegram и узлом. Эти сценарии мы фиксируем письменно, потому что от них зависят и топология каналов, и требования к журналу операций, и глубина проверки на сбои.

1. Аудит платёжных сценариев. Собираем все ветки: входящие и исходящие переводы, возвраты, недоплаты, повторные попытки после истечения счёта. На выходе — перечень состояний бота и правила переходов между ними.
2. Схема движения средств. Описываем, как внутренний баланс пользователя соотносится с остатком на узле, где хранятся ключи и в какой момент операция считается завершённой. Эта схема становится основой учётной логики и реестра операций.
3. Настройка каналов и ликвидности. Определяем число каналов, их распределение по направлениям и пороги автоматической ребалансировки, чтобы входящая ёмкость не заканчивалась в пиковые часы.
4. Проверка на отказоустойчивость. Прогоняем потери узла, недоступность провайдера и устаревшее состояние: восстановление из резервной копии, корректное закрытие каналов, обработку зависших платежей без двойного зачисления.
5. Сверка и мониторинг. Автоматизируем сопоставление внутреннего реестра с состоянием узла и выводим алерты на расхождение, нехватку ёмкости и рост очереди неуспешных операций.
6. Передача и обучение поддержки. Отдаём конфигурации, схемы, инструкции по типовым инцидентам и проводим обучение первой линии: как читать статусы, что эскалировать и какие действия безопасны без инженера.

Что остаётся у вас: конфигурации, схемы, регламенты

Передаём не доступ к боту, а комплект, по которому инфраструктуру можно поднять и сопровождать своей командой. Всё лежит в закрытом хранилище с историей правок: видно, кто и когда менял параметры Lightning-узла, лимиты и правила маршрутизации.

• Конфигурация бота — файлы настроек узла и сервиса, лимиты на разовый платёж и суточный оборот по пользователю, правила выбора маршрута и размер комиссии.
• Схема потоков средств — диаграмма движения средств между кошельками, каналами и резервом, с границей кастодиального контура и перечнем ключей.
• Политики доступа и роли — матрица: кто выводит средства, кто только смотрит, кто меняет конфигурацию; второе подтверждение на критичные операции.
• Регламент реагирования на сбой — что проверяем при недоступности узла, разрыве канала или зависшей транзакции, что перезапускаем и когда эскалируем.
• Документация по схеме — описание архитектуры, точек отказа и порядка восстановления из резервной копии с проверенным временем разворота.
• Мониторинг и оповещения — пороги по балансу каналов, задержке платежей и доле ошибок; уведомления уходят в дежурный канал, а не в личку инженера.

Заканчиваем передаточной сессией: ваша команда воспроизводит восстановление узла на тестовом контуре своими руками и дальше ведёт сопровождение самостоятельно.

Кейс: бот подписок с ростом платежей без обрывов каналов

Что было до перевода

Бот подписок обслуживал несколько тысяч продлений в сутки, и каждый платёж шёл через отдельный канал со своим балансом. На пиках ликвидность расползалась: доля успешных платежей падала до 62%, инвойсы истекали, часть каналов оказывалась в состоянии, где платёж не проходит ни в одну сторону. Повторные списания не были идемпотентными — при таймауте продление уходило вторым инвойсом, и возвраты разбирались вручную.

Что изменили

Собрали кастодиальную схему: единый пул управляемых каналов и ребалансировка по расписанию, плюс триггер при просадке локального баланса ниже порога. Каждое продление получило фиксированный идентификатор — повторная попытка возвращает результат первой, а не создаёт новое списание. На пиках продления идут через очередь с ограничением параллелизма, чтобы поток не выедал ликвидность одного узла.

Метрики до и после

• Доля успешных платежей: 62% → 96% в обычные сутки и не ниже 94% при четырёхкратной пиковой нагрузке.
• Повторные списания: 1,8% → 0,02% от числа продлений.
• Восстановление после отказа узла: с 40 минут ручных переключений до 3 минут автоматического перевода на резервный.

Схема работает на Lightning Network; отказоустойчивость держится на автоматике, а не на дежурном инженере, — поэтому рост числа подписчиков больше не упирается в ручные разборы.

Что делать, если бот уже работает и нужен приём оплаты

Работающий бот — это постоянный поток запросов и живая база, поэтому доработка существующего бота начинается не с правки кода, а с разделения контуров: новый приём платежей поднимается рядом с боевым и пишет в те же таблицы, а текущие сценарии продолжают обслуживаться. Добавление оплаты в бота не требует паузы — старые обработчики остаются включёнными, пока новые проходят проверку на реальных операциях ограниченного объёма.

Меняется только слой подтверждения: вместо ручной сверки появляется узел Lightning Network с каналами, входящей ликвидностью и привязкой подтверждения к конкретному счёту. Логика самого бота — команды, роли, меню, выдача доступа — остаётся прежней, потому что она не знает, откуда пришло подтверждение.

Миграция без остановки сервиса идёт этапами: сначала расширение схемы с обратной совместимостью (новые поля необязательные, старый код их игнорирует), затем теневой режим, когда оплата принимается, но зачисление сверяется с текущим механизмом, и только после совпадения — переключение. Откат — одна настройка, возвращающая прежний путь подтверждения.

Совместимость с текущей базой упирается в один вопрос: есть ли у вас внутренний идентификатор пользователя, не зависящий от мессенджера. Если да, платёж связывается с ним напрямую, а журнал операций, куда записи только добавляются, закрывает сверку и разбор расхождений запросом вместо чтения логов.

Отдельно проектируем кастодиальную часть: где лежат ключи, кто инициирует возврат, что происходит при нехватке входящей ликвидности и как бот ведёт себя при недоступности узла. Эти сценарии проверяются до включения приёма — иначе первый сбой случится ровно на первой же крупной операции.

Технические вопросы: ликвидность, ключи, отказоустойчивость

Технические сомнения вокруг кастодиального бота в Lightning Network сводятся к границе ответственности: что контролирует сервис, а что остаётся на стороне пользователя. Ниже — ответы на вопросы, которые чаще всего всплывают до начала разработки.

Как защищены ключи?

Основная масса средств лежит вне горячего контура, узел работает с ограниченным операционным остатком. Ключи не покидают защищённую среду, доступ разграничен по ролям и логируется.

Что происходит при перезапуске узла?

Состояние каналов фиксируется на диске, после старта узел восстанавливает соединения и досинхронизируется. Платежи на это время встают в очередь и уходят после подъёма, дубли исключены по идентификатору операции.

Что делать при нехватке ликвидности?

Входящая и исходящая ликвидность распределяется по каналам; при перекосе запускается перебалансировка или открываются новые. Пороги предупреждают заранее, часть платежей идёт резервным маршрутом.

Можно ли сменить модель хранения?

Переход к самостоятельному хранению ключей пользователем возможен, но это переработка учёта, выдачи ключей и миграции активных каналов — планируем отдельным этапом.

Обсудим задачу: разберём схему и вернёмся с оценкой

Чтобы вернуться с оценкой и планом работ, а не с примерной вилкой «плюс-минус», нам нужны входные данные от заказчика. Разбор начинается со сценариев оплаты: кто пополняет баланс, что происходит при обрыве связи и как бот должен себя вести в этот момент. По этим ответам видно, какие части кастодиальной схемы ложатся на сервер, а какие остаются на стороне узла Lightning Network.

Что подготовить к разговору:

• Сценарии оплаты: приём, выплата, перевод между сетями, разбивка крупной суммы на части.
• Объёмы: пиковая нагрузка, суточное число операций, ожидаемый рост, средний и максимальный платёж.
• Требования к возвратам: сроки, частичный возврат, спорные операции, ручное подтверждение администратором.
• Роли доступа: кто видит баланс, кто инициирует выплату, нужны ли подтверждения второго лица, как ведётся журнал действий.
• Ограничения по поддержке: режим работы, допустимое время простоя, кто на стороне заказчика реагирует на сбои.
• Порядок передачи проекта: исходники, схема инфраструктуры, инструкции для дежурного, обучение команды.
• Текущая инфраструктура: свой узел или сторонний, какие интеграции с учётом и отчётностью обязательны.

Дальше собираем схему и оцениваем трудозатраты по этапам. Если часть данных пока неизвестна, фиксируем допущения и проверяем их на первом шаге — так требования к возвратам и порядок передачи проекта не всплывут сюрпризом в середине работы. Опишите задачу в удобном виде, и мы вернёмся с планом.