Розробляємо платіжні шлюзи на 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 та кращу екосистему інструментів.
| Параметр | LND | CLN | Eclair |
|---|---|---|---|
| API | gRPC+REST | JSON-RPC | REST (Phoenix) |
| Документація | Відмінна | Добра | Середня |
| Інструменти | Loop, Pool | plugins | Вбудований wallet |
Які інструменти потрібні для розробки платіжного шлюзу на Lightning Network?
Для швидкого старту знадобиться: Bitcoin full node (синхронізація ~600GB NVMe), LND поверх bitcoind, мінімальний капітал 0.1–0.5 BTC для відкриття каналів, та сервер з постійним storage. Ми використовуємо Go для core-логіки та Python для скриптів ребалансування.
Налаштування LND ноди
Налаштування 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} 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
| Метод | Endpoint | Опис |
|---|---|---|
| POST | /api/invoices | створити інвойс |
| GET | /api/invoices/:hash | статус інвойсу |
| WS | /api/invoices/stream | real-time події оплати |
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 для малого шлюзу
Як розпочати: покроковий план
- Встановлення Bitcoin Core ноди (синхронізація ~600GB NVMe).
- Встановлення та налаштування LND.
- Відкриття початкових каналів (0.1-0.5 BTC).
- Налаштування Loop Out для ребалансування.
- Інтеграція з вашим backend.
- Запуск у продакшен.
Розробка базового Lightning платіжного шлюзу зі створенням інвойсів, моніторингом оплат та автоматичним Loop Out — 6–8 тижнів. З повним ліквідіті-менеджментом, BOLT-12 підтримкою та admin дашбордом — 3–4 місяці. Зв'яжіться з нами, щоб оцінити ваш проєкт.