Разработка платежного шлюза на Lightning Network под ключ

Разрабатываем платёжные шлюзы на Lightning Network для приёма микроплатежей в Bitcoin. Это принципиально другая модель расчётов: off-chain каналы с on-chain settlement. Перед тем как строить шлюз, нужно понять, что Lightning — это сеть ликвидности, и управление этой ликвидностью — основная операционная задача, которой нет в аналогах на базе L1. Неправильный менеджмент каналов приводит к потере до 30% платежей из-за фейлов по пути. Мы, команда блокчейн-инженеров с 5+ годами опыта и 30+ проектами за плечами, строим production-ready решения под ключ: оценим ликвидность, настроим автоматическую ребалансировку и интегрируем с вашим backend.

Получите консультацию на старте — мы поможем избежать типичных ошибок.

Архитектура Lightning: что нужно знать инженеру

Платёж по Lightning Network проходит не напрямую от sender к receiver, а по пути через промежуточные узлы. Узел А → Узел Б → Узел В → Узел Г: каждый промежуточный узел пересылает HTLCs (Hash Time-Locked Contract). Если на каком-то хопе не хватает ликвидности в нужном направлении — платёж фейлится и нужно пробовать другой path.

Для шлюза это означает: inbound ликвидность — критический ресурс. Чтобы принимать Lightning платежи, ваш узел должен иметь inbound capacity от хорошо подключённых узлов сети.

Выбор node implementation

LND vs CLN vs Eclair: мы рекомендуем LND для веб-шлюзов — его API в 2 раза богаче, документации на 40% больше. LND (Go) имеет стабильный gRPC/REST API и лучшую экосистему инструментов.

Какие инструменты нужны для разработки платежного шлюза на Lightning Network?

Для быстрого старта потребуется: Bitcoin full node (синхронизация ~600GB NVMe), LND поверх bitcoind, минимальный капитал 0.1–0.5 BTC для открытия каналов, и сервер с постоянным storage. Мы используем Go для core-логики и Python для скриптов ребалансировки.

Настройка LND ноды

Установка и конфигурация:

lnd --bitcoin.active --bitcoin.mainnet --bitcoin.node=bitcoind \
    --bitcoind.rpchost=localhost --bitcoind.rpcuser=rpcuser --bitcoind.rpcpass=rpcpassword \
    --bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 --bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 \
    --rpclisten=0.0.0.0:10009 --tlsextraip=YOUR_SERVER_IP --alias="YourGateway" --color=#FF6B35

Для API взаимодействия — lnd-grpc клиент. Сертификат и macaroon (credential файл) обязательны для каждого запроса.

Создание инвойса и ожидание оплаты

package lightning

import (
	"context"
	"encoding/hex"
	"time"

	lnrpc "github.com/lightningnetwork/lnd/lnrpc"
	"google.golang.org/grpc"
)

type LNDClient struct {
	conn   *grpc.ClientConn
	client lnrpc.LightningClient
}

func (c *LNDClient) CreateInvoice(ctx context.Context, amountSats int64, memo string, expirySeconds int64) (*Invoice, error) {
	req := &lnrpc.Invoice{
		Value:  amountSats,
		Memo:   memo,
		Expiry: expirySeconds,
	}
	resp, err := c.client.AddInvoice(ctx, req)
	if err != nil {
		return nil, err
	}
	return &Invoice{
		PaymentRequest: resp.PaymentRequest,
		PaymentHash:    hex.EncodeToString(resp.RHash),
		ExpiresAt:      time.Now().Add(time.Duration(expirySeconds) * time.Second),
	}, nil
}

func (c *LNDClient) WatchInvoices(ctx context.Context, handler func(*lnrpc.Invoice)) error {
	stream, err := c.client.SubscribeInvoices(ctx, &lnrpc.InvoiceSubscription{})
	if err != nil {
		return err
	}
	for {
		invoice, err := stream.Recv()
		if err != nil {
			return err
		}
		if invoice.State == lnrpc.Invoice_SETTLED {
			handler(invoice)
		}
	}
}

Как управлять ликвидностью в Lightning Network?

Главная операционная задача для production шлюза. Канал имеет capacity (общий размер) и balance (распределение между сторонами). При приёме платежей balance смещается в вашу сторону — inbound capacity расходуется. При отправке — наоборот.

Loop: submarine swaps

Lightning Loop (Lightning Labs) позволяет перебалансировать канал через submarine swap — атомарный обмен между on-chain BTC и off-chain Lightning sat без закрытия канала:

• Loop Out: переводим Lightning sat → on-chain BTC. Восстанавливает inbound capacity.
• Loop In: переводим on-chain BTC → Lightning sat. Восстанавливает outbound capacity.

# Восстановить 500k sat inbound capacity через Loop Out loop out --amt 500000 --channel YOUR_CHANNEL_ID 

Стоимость: 0.1–0.3% + on-chain fee (примерно $1-2 при текущих комиссиях). Для шлюза с постоянным inflow — автоматический Loop Out при достижении порога (outbound balance > 80% capacity). Это экономит до 2% от суммы платежа — для шлюза с оборотом 10 BTC/мес это около $500 в месяц.

Pool: аренда ликвидности

Lightning Pool — маркетплейс для аренды inbound ликвидности. Продавцы открывают каналы к вашему узлу за комиссию. Срок аренды: 2016 блоков (~2 недели). Альтернатива самостоятельному менеджменту каналов для старта.

Автоматическая ребалансировка

async def auto_rebalance(lnd_client: LNDClient):
    channels = await lnd_client.list_channels()
    for channel in channels:
        balance_ratio = channel.local_balance / channel.capacity
        if balance_ratio > 0.85:
            amount = int((balance_ratio - 0.5) * channel.capacity)
            await loop_out(amount, channel.chan_id)
        elif balance_ratio < 0.15:
            amount = int((0.5 - balance_ratio) * channel.capacity)
            await rebalance_circular(amount, channel.chan_id, lnd_client)

Почему BOLT-12 лучше BOLT-11 для recurring payments?

BOLT-11 — одноразовый инвойс. BOLT-12 Offers — многоразовый переиспользуемый payment код. Клиент запрашивает актуальный инвойс у получателя через onion-сообщение, получает BOLT-11 (или BOLT-12 invoice), платит. Работает для подписок, tips, recurring payments. LND поддерживает BOLT-12 начиная с версии 0.17.

Безопасность

Watchtower: если ваш узел offline, бывший контрагент может попытаться транслировать старое состояние канала (breach attempt). Watchtower-сервис мониторит блокчейн и публикует penalty транзакцию. LND имеет встроенный watchtower client и server.

# Подключение к публичному watchtower lncli wtclient add [email protected]:9911 

Channel backup: SCBs (Static Channel Backups) позволяют восстановить средства из каналов при потере node state. Автоматически создаются LND, нужно хранить в безопасном месте.

Macaroon ограничения: для API доступа приложения выпускаем ограниченные macaroon — только права на создание инвойсов без права инициировать платежи:

lncli bakemacaroon invoices:write invoices:read 

Интеграция с backend

Webhook при оплате — та же схема что для on-chain платёжного шлюза (HMAC-SHA256 подпись). Fiat конвертация: при создании инвойса принимаем fiat сумму, конвертируем в satoshi по текущему курсу (Kraken/Coinbase API), фиксируем курс на время жизни инвойса.

Что входит в разработку

• Документация по интеграции REST API и webhook
• Доступ к дашборду управления ликвидностью
• Обучение команды (2 часа)
• Поддержка в течение 2 недель после запуска
• Исходный код и конфигурация

Инфраструктура

• Dedicated server или VPS (не контейнер без persistent storage)
• Bitcoin full node (потребляет ~600GB NVMe)
• LND поверх bitcoind
• Minimum initial capital для открытия каналов: 0.1–0.5 BTC для малого шлюза

Разработка базового Lightning платёжного шлюза с созданием инвойсов, мониторингом оплат и автоматическим Loop Out — 6–8 недель. С полным ликвидити-менеджментом, BOLT-12 поддержкой и admin дашбордом — 3–4 месяца. Свяжитесь с нами, чтобы оценить ваш проект.