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]