Архитектура и разработка 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, забрав весь баланс Алисы. Это экономический стимул не мошенничать.
Детали 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 недель | 4-6 месяцев |
| Сложность реализации | Средняя (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 недель
- 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 биткоин-платежами. Закажите разработку под ключ и получите надёжное решение для мгновенных микроплатежей.