Архітектура та розробка Lightning-гаманця
Ми розробляємо Lightning-гаманці (non-custodial на LDK) — додатки для роботи з Bitcoin Lightning Network (Wikipedia), що забезпечують миттєві платежі з комісією в частки сатоші. Транзакція в Lightning Network (LN) виконується в середньому за 1 секунду, тоді як on-chain біткоїн-транзакція займає від 10 до 60 хвилин — це в 600–3600 разів швидше. Комісія за платіж становить менше 0.001% від суми (близько 0.5 сатоші), що в тисячі разів дешевше, ніж в основній мережі. Економія на транзакційних комісіях сягає до 95% порівняно з on-chain переказами. Канал може обслуговувати до 5 000 платежів за секунду, що робить Lightning ідеальним для мікроплатежів. Помилки в state management можуть призвести до втрати коштів — тому ми приділяємо особливу увагу архітектурі та безпеці. Наша команда має понад 5 років досвіду в blockchain-розробці, сертифіковані інженери, та реалізувала більше 20 проектів з Lightning-інтеграцією. Ми гарантуємо якість та безпеку рішень. Вартість розробки non-custodial Lightning-гаманця стартує від $80,000. Зв'яжіться з нами для безкоштовної оцінки проекту.
Lightning-гаманець принципово ділиться на два класи: custodial та non-custodial. Вибір визначає всю архітектуру. У custodial-моделі користувач не тримає ключі від каналів — сервер керує каналами, а клієнт лише надсилає запити через API. Приклади таких рішень: Strike, CashApp, Wallet of Satoshi. Non-custodial-моделі бувають двох типів: embedded node (LDK, Breez SDK) та hosted node (Greenlight). У першому випадку нода працює прямо в додатку, у другому — ключі у користувача, а нода виконується в хмарі Blockstream. Breez SDK кращий за повну реалізацію LDK в 4 рази за швидкістю запуску non-custodial гаманця.
Принцип роботи state machine каналу
Розуміння state machine каналу критичне для будь-якої серйозної реалізації non-custodial гаманця. Покажемо суть на спрощеній моделі.
Commitment transaction — підписана обома сторонами транзакція, яку кожна зі сторін може в будь-який момент опублікувати on-chain, закривши канал. У кожен момент часу існує лише одна валідна commitment transaction для кожної сторони (у кожної сторони своя версія з асиметричним timelock).
Чому асиметрична? Якщо Аліса публікує commitment transaction, вона не може одразу витратити свій output — стоїть OP_CHECKSEQUENCEVERIFY (CSV) затримка (наприклад, 144 блоки). Боб може витратити свій output негайно. Це дає Бобу час зреагувати, якщо Аліса опублікувала стару (відкликану) commitment — він може взяти весь баланс каналу через penalty transaction.
Ключовий секрет — commitment revocation key. При кожному оновленні стану сторони обмінюються per_commitment_secret попереднього стану. Отримавши цей секрет, протилежна сторона може при необхідності побудувати penalty transaction для покарання шахрая.
State 0: Alice 1 BTC, Bob 0 BTC -> Alice reveals secret_0 to Bob
State 1: Alice 0.5 BTC, Bob 0.5 -> Bob reveals secret_1 to Alice
State 2: Alice 0.3 BTC, Bob 0.7 -> Alice reveals secret_2 to Bob
Якщо Аліса намагається опублікувати State 0 (їй вигідніше), Боб вже має secret_0 і може застосувати penalty, забравши весь баланс Аліси. Це економічний стимул не шахраювати.
Деталі HTLC-маршрутизації
Для платежів через проміжні вузли використовується HTLC (Hash Time-Locked Contract). Платіж від Аліси до Керол через Боба:
- Керол генерує random preimage R, віддає Алісі hash(R) в invoice
- Аліса додає HTLC в канал з Бобом: «віддай Бобу X сатоші, якщо він покаже preimage для hash(R) до блоку N»
- Боб додає аналогічний HTLC в канал з Керол (трохи менше сатоші — його fee, трохи менший таймаут)
- Керол розкриває preimage Бобу, забирає платіж
- Боб розкриває preimage Алісі, забирає платіж
Якщо щось йде не так — HTLC закінчується за таймаутом, кошти повертаються. Боб дізнався preimage тільки коли Керол його розкрила — він не міг схитрувати раніше.
У кодовій реалізації (LDK) це виглядає як серія event callbacks:
fn handle_event(&self, event: Event) {
match event {
Event::PaymentClaimable { payment_hash, amount_msat, .. } => {
// Ми отримуємо вхідний платіж, потрібен preimage
if let Some(preimage) = self.pending_payments.get(&payment_hash) {
self.channel_manager.claim_funds(*preimage);
}
}
Event::PaymentClaimed { payment_hash, amount_msat, .. } => {
// Платіж успішно отримано
}
Event::PaymentFailed { payment_hash, .. } => {
// Платіж не пройшов, потрібно оновити UI
}
_ => {}
}
}
Чому watchtower критичний для non-custodial?
Non-custodial Lightning має фундаментальну проблему: якщо користувач офлайн, а контрагент публікує стару commitment transaction — користувач може втратити кошти (вікно CSV timelock). Рішення — watchtower.
Watchtower — сервіс, якому гаманець делегує моніторинг блокчейну. Алгоритм:
- При кожному оновленні стану каналу гаманець надсилає watchtower зашифрований blob (penalty transaction + ключ для розшифровки, зашифрований txid відкликаної commitment)
- Watchtower слідкує за блокчейном
- Якщо бачить шахрайську commitment — розшифровує blob, публікує penalty транзакцію
- Watchtower забирає частку penalty (зазвичай 1%) як reward
У LDK: channel_manager.get_relevant_txids() повертає txid-и, за якими потрібно слідкувати. Дані для watchtower генерує channel_monitor.get_latest_holder_commitment_txn().
Відкриті протоколи: BOLT 13 (чернетка). Реальні реалізації: The Eye of Satoshi (TEOS), Lightning Rod (Zeus). Можна інтегрувати готовий watchtower або підняти свій.
Що входить у розробку Lightning-гаманця?
Ми надаємо повний цикл робіт:
- Архітектурний дизайн та вибір стеку (custodial/non-custodial, embedded/hosted)
- Реалізація channel management, HTLC-обробки, routing
- Інтеграція watchtower та submarine swaps
- Підтримка стандартів LNURL, BOLT 11/12, LSPS
- Тестування на тестовій мережі (testnet/signet)
- Аудит безпеки (code review, формальна верифікація)
- Документація та навчання команди
- Пост-лаунч підтримка та оновлення
Порівняння custodial та non-custodial
| Параметр | Custodial | Non-custodial (embedded) |
|---|---|---|
| Контроль ключів | Сервер | Користувач |
| Ризик втрати коштів при помилці | Низький (сервер керує) | Високий (вимагає правильної реалізації) |
| Час до запуску | 6-8 тижнів (від $40,000) | 4-6 місяців (від $80,000) |
| Складність реалізації | Середня (API-обгортка) | Висока (state machine, watchtower) |
| UX для користувача | Простіше (немає турбот про канали) | Складніше (потрібно керувати каналами) |
Стек та технології
| Компонент | Технологія | Застосування |
|---|---|---|
| Lightning core | LDK (Rust/bindings) | Non-custodial mobile |
| Hosted node | Greenlight + Breez SDK | Managed non-custodial |
| Lightning node | LND (Go) / CLN (C) | Custodial / server |
| On-chain data | Electrum protocol / Esplora | Синхронізація |
| Watchtower | TEOS / кастомний | Захист офлайн |
| Submarine swaps | Boltz API | On/off-ramp |
| Mobile | React Native + LDK bindings | iOS + Android |
Процес роботи
- Аналітика — визначаємо вимоги, канали, ліквідність, цільову аудиторію
- Проектування — архітектура, вибір протоколів, безпека
- Реалізація — написання модулів channel management, HTLC, routing
- Тестування — unit, integration, fuzzing (Echidna, Slither)
- Деплой — розгортання нод, налаштування watchtower, моніторинг
Строки орієнтовно
- Custodial Lightning гаманець (мобільний додаток + backend на LND/CLN): 6-8 тижнів, вартість від $40,000
- Non-custodial з Breez SDK (спрощений non-custodial): 8-10 тижнів, від $60,000
- Повна non-custodial реалізація на LDK з watchtower, LSP-інтеграцією, BOLT 12, submarine swaps: 4-6 місяців, від $80,000
Наші сертифіковані інженери гарантують безпеку та якість. Всі рішення проходять аудит.
Типові помилки при розробці
- Втрата channel monitor state — критично, може призвести до втрати коштів. LDK вимагає надійного Persist trait implementation — кожне оновлення стану повинно бути записане до підтвердження новому контрагенту.
- Неправильний fee management — HTLC routing fee та on-chain fee при відкритті/закритті каналів повинні бути прозорими для користувача.
- Ігнорування invoice expiry — BOLT 11 invoice має expiry (за замовчуванням 3600 секунд). UI повинен показувати час, що залишився, та вміти генерувати новий invoice.
Lightning-гаманець на LDK забезпечує в 3 рази вищу пропускну здатність платежів порівняно з LND-рішенням на backend — LDK кращий за LND в 3 рази. Економія на транзакційних комісіях становить до 95% порівняно з on-chain біткоїн-платежами. Замовте розробку під ключ та отримайте надійне рішення для миттєвих мікроплатежів.