Lightning-гаманець під ключ: архітектура та реалізація

Архітектура та розробка 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, забравши весь баланс Аліси. Це економічний стимул не шахраювати.

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 — сервіс, якому гаманець делегує моніторинг блокчейну. Алгоритм:

1. При кожному оновленні стану каналу гаманець надсилає watchtower зашифрований blob (penalty transaction + ключ для розшифровки, зашифрований txid відкликаної commitment)
2. Watchtower слідкує за блокчейном
3. Якщо бачить шахрайську commitment — розшифровує blob, публікує penalty транзакцію
4. 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

Стек та технології

Процес роботи

1. Аналітика — визначаємо вимоги, канали, ліквідність, цільову аудиторію
2. Проектування — архітектура, вибір протоколів, безпека
3. Реалізація — написання модулів channel management, HTLC, routing
4. Тестування — unit, integration, fuzzing (Echidna, Slither)
5. Деплой — розгортання нод, налаштування 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 біткоїн-платежами. Замовте розробку під ключ та отримайте надійне рішення для миттєвих мікроплатежів.