Lightning Watchtower — сервіс, який стежить за ланцюгом Bitcoin від імені користувача платіжного каналу. Якщо інша сторона публікує відкликаний стан, він може надіслати заздалегідь підготовлену транзакцію повернення коштів. Це допомагає під час відключення вузла, але потребує правильних даних, зв’язку та вчасного підтвердження. Вузол — це програма, яка керує каналами й обробляє платежі Lightning; без підключення вона не може обмінюватися даними з іншими учасниками.
Анна й Павло мають платіжний канал: їхні кошти спільно заблоковані в Bitcoin, а платежі через Lightning змінюють їхній розподіл. Павло платить Анні, обоє погоджують нові баланси й відкликають старий стан. Потім в Анни зникає інтернет. Якби Павло опублікував старий стан, він міг би спробувати повернути вже витрачені гроші. Для такого випадку Анна може підключити Lightning Watchtower. Її вузол заздалегідь передає йому зашифровані дані для захисту відкликаних станів. Коли сервіс розпізнає відповідну транзакцію в ланцюгу, він може надіслати транзакцію повернення коштів без підключеної Анни. Він не здійснює платежі замість неї й не усуває збій її вузла. [1] [8]
Кожному погодженому розподілу коштів відповідає commitment transaction — підписана транзакція, що дозволяє закрити канал у ланцюгу Bitcoin. Під час оновлення учасники обмінюються даними, які дають змогу покарати публікацію попереднього, відкликаного стану. Тут ідеться саме про таку модель каналу зі штрафним механізмом. Якщо Павло використовує поточний чинний стан, він має право закрити канал односторонньо, навіть коли Анна не в мережі. Watchtower не повинен блокувати це закриття. Він реагує на конкретний відкликаний стан, опублікований навмисно чи помилково зі старої резервної копії. Важливе відкликання стану, а не вік транзакції. [1] [8]
Seed Phrase — резервна копія у вигляді слів, з якої можна відновити приватні ключі для підписання платежів. LND — одна з програм для роботи вузла Lightning. Анна не передає сервісу Seed Phrase або приватні ключі всього гаманця. Вона надає обмежений набір даних і підписів для конкретного втручання; у LND цей пакет називається JusticeKit. Транзакція повернення коштів, відома як justice transaction, повертає захищені кошти за заздалегідь підготовленими умовами. Це не дає Watchtower права довільно витрачати інші монети Анни. У моделі без винагороди сервісу із захищеної суми віднімається комісія транзакції Bitcoin. Код передбачає і типи з винагородою для вежі, але сама їхня наявність не доводить, що певний оператор пропонує платну послугу. [3] [4] [5]
Щоб Watchtower міг допомогти, він має справді отримати потрібні дані. Самого введення адреси в налаштуваннях або завдання в черзі на відправлення недостатньо. Клієнт — частина вузла Анни, яка спілкується з вежею, — повинен отримувати підтвердження прийняття оновлень. Зв’язок може обірватися, угода про зберігання під назвою session може вичерпати місткість, а резервну копію можуть відхилити. Тому Анні потрібно стежити й за недоставленими оновленнями та помилками. Навіть прийняті дані не гарантують успіху: вежа має далі стежити за правильним ланцюгом, а її реакція повинна вчасно підтвердитися в блоці. [6] [8]
Якщо Анна втратить пристрій, відновлювати його з Watchtower вона не буде. Сервіс стежить за зловживанням відкликаними станами, але не відновлює гаманець і не рятує від викрадення ключів. Для відновлення каналів LND використовує Static Channel Backup (SCB). Разом із seed гаманця він допомагає повернути кошти через закриття каналів, а не продовжити роботу точно з місця зупинки вузла. SCB — не копія кожного оновлення й не зашифрований пакет для вежі. Особливо небезпечно запускати стару базу channel.db без належної процедури відновлення: вузол може опублікувати власний відкликаний стан. Готуй резервні копії за документацією конкретного гаманця та його версії. [7]
Вихід транзакції визначає суму та умови, за яких її можна витратити. Захист працює завдяки тому, що учасник, який публікує свій стан каналу, не може одразу витратити свій відкладений вихід. У BOLT 3 цей вихід називається to_local, а затримка — to_self_delay. CSV — правило, яке відлічує її в блоках від підтвердження виходу. Інша сторона з відповідним ключем відкликання може скористатися штрафним шляхом без цього очікування. Це дає Watchtower перевагу в часі. Після затримки штрафний шлях не зникає, але кошти вже може витратити й інша сторона. Результат залежить від того, яка з несумісних витрат отримає дійсне підтвердження. Самого надсилання транзакції повернення недостатньо, а кількість блоків — не точна кількість годин. [1] [9]
Перед вибором сервісу з’ясуй, що саме він захищає. HTLC — умовні платежі, які можуть ще чекати завершення в каналі; нагляд за балансами не доводить, що вони також захищені. Dust тут означає вихід, замалий для включення до цієї транзакції. Перевірений backupTask у LND v0.21.3-beta готує наявні виходи to_local і to_remote відкликаного commitment, які не є dust. Він не забезпечує загального захисту всіх виходів HTLC; відповідна документація описує це як майбутнє розширення. Bitcoin Script — мова для опису умов витрачання виходу. Можливість витратити вихід штрафним шляхом ще не означає, що конкретна вежа отримала потрібні дані й здатна забезпечити такий захист. [3] [5]
Зашифрований пакет не вимагає, щоб вежа постійно читала всі баланси Анни. Вона шукає збіг за короткою міткою й розшифровує дані за відомостями з розпізнаної транзакції. Далі наведено технічну довідку для конкретної версії LND; txid — ідентифікатор транзакції, а blob — пакет даних. У LND v0.21.3-beta BreachHint — перші 16 байтів SHA-256 бінарного txid. BreachKey отримують через SHA-256 того самого бінарного txid, з’єднаного із самим собою. Це не перші 16 символів відображеного txid і не просто його перша половина. Клієнт шифрує JusticeKit; знання відповідної транзакції дає змогу вивести ключ і розшифрувати дані. [2] [3]
Запускати вежу для інших і доручати нагляд за власними каналами — різні завдання. Ці налаштування призначені операторам LND; RPC — інтерфейс, через який програма отримує команди. LND розділяє watchtower.active для сервера та wtclient.active для клієнта. Саме ввімкнення сервера не налаштує резервування власних каналів на іншій вежі. lncli tower info показує pubkey, listeners і uris сервера; lncli wtclient add реєструє вежу для клієнта. Відкритий ключ вежі відрізняється від ключа вузла Lightning. Перевір мережу, доступність адреси й підтримку RPC у використаній збірці. [5]
Втручання має оплатити місце в блоці Bitcoin. Сатоші — найменша одиниця біткоїна. Віртуальний байт вимірює розмір транзакції з урахуванням різної ваги її частин. Ставка визначається в сатоші за віртуальний байт транзакції, а не у відсотках від захищених коштів. У LND v0.21.3-beta поле sweep_sat_per_vbyte у policy та session задає ставку в sat/vB. Комісія зменшує повернену суму. backupTask може відхилити стан із замалою вартістю або непридатними параметрами session; не кожне підготовлене завдання є придатною резервною копією. Пізніша зміна налаштувань не доводить зміни раніше підписаних транзакцій, а недостатня ставка може затримати реакцію. [3] [6]
Друга вежа допоможе при збої першої лише тоді, коли сама отримала потрібні дані. Незалежність стосується також з’єднання й оператора, а не тільки назви сервісу. Кілька незалежних веж і власний нагляд можуть зменшити наслідки одного збою. Однак перевір, які саме оновлення отримала кожна вежа; кілька зареєстрованих адрес самі собою не доводять реплікації всіх станів. Окремі машини, мережі та місця розташування зменшують спільні відмови. Зашифровані blob і автентифіковані з’єднання обмежують видимість балансів, але не усувають метадані, розкриття частоти оновлень чи ризик кореляції. [5] [8]
Перевіряючи захист, насамперед відрізняй надіслане оновлення від справді отриманого. Ці команди й поля — докладніша довідка для адміністраторів LND; підтвердження прийняття копії вежею не є підтвердженням транзакції в блоці. Використовуй lncli wtclient towers, lncli wtclient tower, lncli wtclient stats і lncli wtclient policy. У LND v0.21.3-beta розрізняй num_backups і num_pending_backups; друге поле рахує резервні копії, які чекають підтвердження вежі. num_failed_backups у відповіді stats рахує невдалі непідтверджені копії. Статистика охоплює час від запуску клієнта. active_session_candidate позначає кандидата для сесій, а не доказ повного захисту. [6]
Правильне налаштування — це початок. Тест має охоплювати весь шлях від виявлення відкликаного стану до повернення захищених коштів; не проводь такий дослід зі своїми справжніми грошима. Перевір конкретні версії клієнта й вежі, підтримувані типи каналів і session, актуальність даних, комісії та синхронізацію з ланцюгом. Функціональну перевірку реакції проводь в ізольованому тестовому середовищі; звичайне одностороннє закриття (force close) не доводить реакції на відкликаний стан. Результат підтверджують публікація відкликаного стану (breach), зібрана justice transaction та її підтверджені виходи. Успішна демонстрація не гарантує майбутньої доступності й не усуває всіх ризиків Lightning. [1] [3] [6]
Для повної картини прочитайте також Lightning Network, Payment Channel, Самостійне зберігання. На цю статтю також посилаються Payment Channel.