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

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1306 услуг
Разработка платежного шлюза на Lightning Network
Сложный
~1-2 недели
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1286
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1198
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    902
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1122
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    589
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    859

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

Lightning Network — это не просто "быстрый Bitcoin". Это принципиально другая модель расчётов: off-chain каналы с on-chain settlement. Перед тем как строить платёжный шлюз, нужно понять, что Lightning — это сеть ликвидности, и управление этой ликвидностью — основная операционная задача, которая нет в аналогах на базе L1.

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

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

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

Выбор node implementation

LND (Lightning Labs, Go): наиболее распространённый, богатый gRPC/REST API, хорошая документация. Рекомендуется для большинства production шлюзов.

CLN (Core Lightning, Blockstream, C): более модульная архитектура, plugin система. Чуть более сложный API.

Eclair (ACINQ, Scala): используется в Phoenix wallet backend. Менее распространён для серверного использования.

Для шлюза выбираем LND — лучший API и экосистема инструментов.

Настройка 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"
    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, // рекомендуется 300–900 секунд
    }
    
    resp, err := c.client.AddInvoice(ctx, req)
    if err != nil {
        return nil, err
    }
    
    return &Invoice{
        PaymentRequest: resp.PaymentRequest, // BOLT-11 строка для клиента
        PaymentHash:    hex.EncodeToString(resp.RHash),
        ExpiresAt:      time.Now().Add(time.Duration(expirySeconds) * time.Second),
    }, nil
}

BOLT-11 строка (lnbc500u1p...) — это QR-код и ссылка для клиента. Wallet декодирует её и знает куда платить.

Подписка на settled инвойсы

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)
        }
    }
}

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

Управление ликвидностью

Главная операционная задача для 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. Для шлюза с постоянным inflow — автоматический Loop Out при достижении порога (outbound balance > 80% channel capacity).

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
        
        # Слишком много исходящей ликвидности — делаем Loop Out
        if balance_ratio > 0.85:
            amount = int((balance_ratio - 0.5) * channel.capacity)
            await loop_out(amount, channel.chan_id)
        
        # Слишком мало — платим через этот канал или делаем Loop In
        elif balance_ratio < 0.15:
            amount = int((0.5 - balance_ratio) * channel.capacity)
            await rebalance_circular(amount, channel.chan_id, lnd_client)

BOLT-12 Offers: следующее поколение инвойсов

BOLT-11 — одноразовый инвойс. BOLT-12 Offers — многоразовый переиспользуемый payment код:

lno1qgsyxjtl6luzd9t3pr62xr7eemp6awnejusgd4...

Клиент запрашивает актуальный инвойс у получателя через 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

REST API обёртка над LND для merchant приложений:

POST /api/invoices          - создать инвойс
GET  /api/invoices/:hash    - статус инвойса
WS   /api/invoices/stream   - real-time события оплаты

Webhook при оплате — та же схема что для on-chain платёжного шлюза (HMAC-SHA256 подпись).

Fiat конвертация: при создании инвойса принимаем fiat сумму, конвертируем в satoshi по текущему курсу (Kraken/Coinbase API), фиксируем курс на время жизни инвойса.

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

  • 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 месяца.