HTLC

Анна хоче надіслати Павлу 20 000 sat через Lightning Network. Sat — скорочення від satoshi, найменшої одиниці біткоїна в блокчейні. Спільного платіжного каналу немає, але обидва мають відповідне з’єднання через Єву. Канал — домовленість двох учасників про розподіл біткоїнів, яку можна оновлювати без запису кожного платежу в блок. Єва пропонує Павлу умовні 20 000 sat, а Анна пропонує Єві 20 010 sat. Різниця 10 sat у цьому спрощеному прикладі є комісією Єви. Це пов’язані зміни балансів у двох каналах, а не рух тієї самої окремої монети. Павло знає секрет, що дозволяє виконати його умову. Єва потім використовує те саме значення у відносинах з Анною. Їй не треба спочатку безповоротно платити Павлу лише під його обіцянку. Суми ілюструють механізм, а не звичайну чи рекомендовану комісію. [1]

Павло готує для платежу випадковий секрет із 32 байтів, payment_preimage. SHA-256 обчислює з нього payment_hash. Перевірити, чи дає розкрите значення потрібний відбиток, легко; відновити добре вибраний секрет лише за відбитком практично неможливо. Звичайний рахунок BOLT 11, тобто запит на платіж Lightning, містить хеш у полі p, а не саму preimage. Коли Павло виконує умову платежу, секрет повертається маршрутом і пов’язує відповідні HTLC. payment_secret у полі s — інше значення: воно допомагає одержувачу правильно обробити платіж і не замінює preimage. Жодне з цих значень не є Seed Phrase (словами для відновлення гаманця) або приватним ключем гаманця. [1] [4]

Якби строки обох платежів збігалися, Павло міг би розкрити секрет надто пізно, щоб Єва встигла отримати вхідний платіж. Тому вхідний HTLC від Анни спливає пізніше за вихідний HTLC Єви до Павла. Різниця cltv_expiry_delta дає Єві запас. Він потрібен і тоді, коли інша сторона перестає відповідати та домовленість доводиться виконувати транзакціями Bitcoin у блокчейні. Запас вимірюється блоками, не точними хвилинами, і має враховувати затримки та реорганізації. Безпечне налаштування визначають програма й правила каналу; замалий запас загрожує коштам. Під час реорганізації частина ланцюга замінюється іншою дійсною гілкою, що може змінити попередні підтвердження транзакцій. [1]

У Lightning cltv_expiry задає висоту блока, його місце в ланцюзі. Це не Unix timestamp (календарний час, виражений кількістю секунд) і не строк дії рахунка BOLT 11 у секундах. Після виконання часових умов може відкритися timeout — шлях розрахунку без секрету. Кошти самі не рухаються: вузли Lightning, тобто програми, що керують платіжними каналами, мають правильно завершити зміну каналу або використати відповідну транзакцію в блокчейні. Дійсна preimage також не припиняє працювати автоматично після спливання строку. Якщо той самий вихід, тобто суму з правилами витрачання, ще не витрачено іншим способом, дозволені шляхи можуть конкурувати; обидва витрачання не можуть підтвердитися в одному дійсному ланцюзі. Тому своєчасна дія є частиною безпеки. [1] [4] [5]

HTLC пов’язує умови, але не дозволяє будь-якій сумі пройти будь-яким маршрутом. Єві потрібні достатні кошти у вихідному напрямку, тобто ліквідність, і вільне місце для ще одного HTLC в очікуванні. Ліміти, комісії чи недоступний вузол можуть зупинити платіж. Поки спробу належно не завершено, частина коштів може залишатися заблокованою. Статус гаманця описує всю спробу; окреме повідомлення не доводить її результату. Розкриття preimage не є підтвердженням транзакції Bitcoin. Звичайний успішний платіж Lightning завершується змінами каналів, без нового запису кожного платежу в блок. [1] [3]

Наступні розділи — технічна довідка. Стан каналу показує, кому належить кожна сума та які HTLC ще очікують. Commitment transaction — підписана транзакція Bitcoin, що дозволяє розрахуватися відповідно до цього стану у блокчейні. update_add_htlc лише пропонує додавання; update_fulfill_htlc повідомляє про виконання, а update_fail_htlc — про невдачу. Оголосити зміну недостатньо. Через commitment_signed і revoke_and_ack сторони обмінюються підписами нового стану та даними, які роблять використання старого небезпечним. За BOLT 2 обидві сторони мають безвідклично прийняти відповідну зміну, перш ніж на неї спиратиметься наступне зобов’язання. Ця згода учасників не є підтвердженням у блоці. Натомість фінансування й можливе закриття каналу спираються на транзакції Bitcoin. [1]

Поля — окремі значення повідомлення. Millisatoshi дорівнює тисячній частині satoshi й є обліковою одиницею всередині Lightning; окремо витратити таку частку в блокчейні Bitcoin не можна. Основа повідомлення update_add_htlc містить channel_id, id, amount_msat, payment_hash, cltv_expiry та onion_routing_packet. amount_msat задається в millisatoshi. Вузол перевіряє обмеження каналу, доступну ліквідність і умови пересилання; вихідний HTLC має власні параметри. Відповідний HTLC не можна пропонувати, поки додавання вхідного не зафіксовано безвідклично за BOLT 2. [1]

Onion routing упаковує вказівки кожному посереднику в окремі зашифровані шари. Єва отримує дані для свого кроку, а не відкритий список усіх учасників. Вузол розшифровує власний шар onion і перевіряє його цілісність. На звичайному незасліпленому маршруті він зіставляє amt_to_forward та outgoing_cltv_value із вхідною сумою, комісією та необхідною часовою різницею. Пакет не відкриває йому весь маршрут. Це не виключає кореляції трафіку чи іншого встановлення особи; onion routing не гарантує абсолютної анонімності. [3]

Вихід — сума з правилами витрачання, записаними мовою Script. Offered і received означають запропонований та отриманий HTLC з погляду учасника каналу. Другий етап — наступна транзакція; CHECKSEQUENCEVERIFY (CSV) задає очікування від підтвердження виходу, який витрачається. Ключ відкликання дозволяє застосувати штраф за оприлюднений старий, уже відкликаний стан. BOLT 3 розрізняє виходи offered і received та шляхи HTLC-success або HTLC-timeout. Самого знання хешу недостатньо: діють відповідні підписи, preimage і часові умови. Локальний вихід другого етапу має CSV-затримку to_self_delay, а правильний ключ відкликання дозволяє контрагенту використати штрафну гілку без цієї затримки. Точний Script залежить від типу каналу. [2] [6]

Trimming означає, що малий HTLC не стає окремим виходом, коли стан каналу потрапляє в блокчейн. Dust — назва таких малих сум. Dust exposure вимірює їхню сукупну вартість, на яку поширюється це обмеження. Якщо сума після відповідної комісії другого етапу нижча за dust_limit_satoshis, commitment-транзакція не створює вихід HTLC. Правила залежать від узгодженого типу: option_anchors і zero_fee_commitments не мають такої комісії другого етапу; zero_fee_commitments може спрямувати обрізану суму до shared_anchor. Відсутній вихід не можна окремо стягнути в блокчейні. Сукупність таких HTLC утворює dust exposure. [2] [1]

Наступна перевірка призначена операторам вузлів і розробникам. Декодування перетворює запис на читабельні поля; воно нічого не надсилає та саме по собі не доводить виконання всіх умов. Порівняй вхідні й вихідні amount_msat, payment_hash та cltv_expiry; перевір preimage через SHA-256. Відстежуй також commitment_signed, revoke_and_ack і кінцевий стан, а не лише одне повідомлення fulfill/fail. Для виконання в блокчейні декодуй справжню commitment-транзакцію, перевір наявність виходу, використану гілку та HTLC-success/HTLC-timeout. Перевір підписи, часові умови й підтвердження; саме декодування не доводить дійсність. [1] [2]