Разработка Lightning-кошелька под ключ: архитектура, реализация, аудит

Архитектура и разработка Lightning-кошелька

Мы разрабатываем Lightning-кошельки — приложения для работы с Bitcoin Lightning Network, которые обеспечивают мгновенные платежи с комиссией в доли сатоши. Транзакция в Lightning Network выполняется в среднем за 1 секунду, тогда как on-chain биткоин-транзакция занимает от 10 до 60 минут. Комиссия за платеж составляет менее 0.001% от суммы — это в тысячи раз дешевле, чем в основной сети. Экономия на транзакционных комиссиях доходит до 95% по сравнению с on-chain переводами. Канал может обслуживать до нескольких тысяч платежей в секунду, что делает Lightning идеальным для микроплатежей и частых переводов. Ошибки в state management могут привести к потере средств — поэтому мы уделяем особое внимание архитектуре и безопасности. Наша команда имеет более 5 лет опыта в blockchain-разработке и реализовала более 20 проектов с Lightning-интеграцией. Мы работаем с полным стеком: от embedded-решений на LDK до custodial на LND/CLN. Получите бесплатную оценку проекта за 2 дня.

Lightning-кошелек принципиально делится на два класса: custodial и non-custodial. Выбор определяет всю архитектуру. В custodial-модели пользователь не держит ключи от каналов — сервер управляет каналами, а клиент только отправляет запросы через API. Примеры таких решений: Strike, CashApp, Wallet of Satoshi. Non-custodial-модели бывают двух типов: embedded node (LDK, Breez SDK) и hosted node (Greenlight). В первом случае нода работает прямо в приложении, во втором — ключи у пользователя, а нода исполняется в облаке Blockstream. Breez SDK позволяет запустить non-custodial кошелек в 4 раза быстрее, чем полная реализация на LDK.

Как работает state machine канала?

Понимание state machine канала критично для любой серьёзной реализации. Покажу суть на упрощённой модели.

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 недель
• Non-custodial с Breez SDK (упрощённый non-custodial): 8-10 недель
• Полная non-custodial реализация на LDK с watchtower, LSP-интеграцией, BOLT 12, submarine swaps: 4-6 месяцев

Стоимость рассчитывается индивидуально. Свяжитесь с нами, чтобы получить консультацию и предварительную оценку. Наши инженеры имеют более 5 лет опыта в blockchain и реализовали более 20 проектов с Lightning-интеграцией.

Типичные ошибки при разработке

• Потеря 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. Экономия на транзакционных комиссиях составляет до 95% по сравнению с on-chain биткоин-платежами. Закажите разработку под ключ и получите надёжное решение для мгновенных микроплатежей.