---
title: "Хешированный контракт с временной блокировкой (HTLC)"
description: "HTLC позволяет получить платёж по прообразу до срока и вернуть его другим путём после срока. Разберём его роль в платёжных каналах и атомарных свопах, а также риски."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Хешированный контракт с временной блокировкой (HTLC)

> Только для обучения; не является инвестиционной, юридической или технической рекомендацией. Безопасность HTLC зависит от точных скриптов или контрактов, правил сетей, политики подтверждений, комиссий, мониторинга и своевременных действий.

<a id="answer"></a>

## Краткий ответ

Хешированный контракт с временной блокировкой (HTLC) — условный платёж с двумя конкурирующими путями расходования. До срока получатель раскрывает значение `x`, хеш которого совпадает с обязательством `h = H(x)`, и выполняет требования подписей или полномочий. После срока плательщик использует возврат. Точный порядок на границе задают сеть и контракт, а не слово «до».

Хеш-блокировка связывает действия: узнав тот же прообраз после исходящего платежа, участник может погасить связанный входящий платёж. Временная блокировка ограничивает срок условия. Платёжные каналы так маршрутизируют платежи, а атомарные свопы координируют переводы в разных системах.

HTLC не становится автоматически недоверительным, атомарным, приватным или самоисполняемым. Нужны корректный код, совместимое кодирование, разнесённые сроки, предположения о финальности, комиссии, наблюдение и своевременные подтверждения. HTLC Lightning — конкретная спецификация Bitcoin; контракт другой сети может отличаться.

- **Хеш-ветвь:** раскрыть прообраз и выполнить полномочия успешного пути, пока он действителен.
- **Временная ветвь:** выполнить полномочия возврата после созревания абсолютной или относительной блокировки.

<a id="mechanism"></a>

## Как это работает

Боб выбирает новый непредсказуемый прообраз `x`, вычисляет `h = H(x)` и передаёт `h` Алисе. Алиса блокирует средства по правилам, фиксирующим `h`, уполномоченных лиц и срок `T`.

- Алиса до финансирования проверяет алгоритм, кодирование, сумму, актив, получателя, адрес возврата, сеть и срок.
- Боб проверяет реально профинансированный выход или развёрнутый контракт, а не черновик или интерфейс.
- Для успешного пути Боб предоставляет `x`; логика проверяет `H(x) = h` и полномочия.
- Публикация или передача `x` может позволить Алисе либо посреднику погасить другой HTLC с тем же хешем платежа.
- Если успех не использован вовремя, возврат становится допустим в `T`; сам по себе он не отправляется и не подтверждается.
- Участник должен подготовить или сохранить транзакцию, назначить достаточную комиссию, отправить её, следить за заменами и конфликтами и получить подтверждения.
- После раскрытия `x` контрагенту или публичной сети считайте его известным и не используйте для иной цели.

Bitcoin различает абсолютные и относительные блокировки. `OP_CHECKLOCKTIMEVERIFY` из BIP 65 запрещает трату до высоты или времени блока из locktime; `OP_CHECKSEQUENCEVERIFY` из BIP 112 ждёт относительный возраст входа. Поля транзакции тоже должны быть совместимы. Временная блокировка — правило проверки, а не планировщик.

В Lightning сообщение `update_add_htlc` несёт сумму, `payment_hash` и `cltv_expiry`. Каждый узел назначает исходящему HTLC более ранний срок, чем входящему, оставляя время взыскать выше по маршруту после получения прообраза. BOLT 3 задаёт выходы обязательств, пути `HTLC-success` и `HTLC-timeout`, подписи, отзыв, отсечение пыли и задержки; двух ветвей недостаточно для полного канала.

<a id="example"></a>

## Пример

В учебном примере Алиса меняет `1 BTC` на `20 ETH` Боба. Он показывает только порядок: рабочая система требует проверенного кода для каждой сети и не должна копировать эти условные интервалы.

- Алиса создаёт новые `x` и `h = H(x)` и блокирует `1 BTC`: Боб взыскивает по прообразу, Алиса возвращает после `48 hours`.
- Проверив транзакцию Bitcoin и политику подтверждений, Боб блокирует `20 ETH` с совместимым хешем и кодированием; путь Алисы заканчивается через `24 hours`, затем доступен возврат Боба.
- До раскрытия `x` ради `20 ETH` Алиса проверяет ID Ethereum, байткод, адрес, актив, сумму, стороны, `h` и оба пути.
- Боб получает `x` из взыскания или согласованного сообщения и пытается провести успешный путь Bitcoin до позднего срока.
- Если обмен остановлен до раскрытия, каждый возврат становится допустим лишь по правилам своей сети и должен быть отправлен и подтверждён.

Разница между `48 hours` и `24 hours` — резерв реакции, а не универсальный параметр. Для обеих систем моделируют реорганизации, время блока, финальность, исполнение, ретрансляцию, мемпул, комиссии, цензуру и задержки. Второй участник не должен продолжать лишь из-за отметки «подтверждено».

<a id="risks"></a>

## Риски

- **Ошибочное обязательство:** алгоритм, длина или кодирование различаются, и один `x` не подходит обеим сторонам.
- **Ошибочный артефакт:** выход, ID сети, адрес, байткод, актив, сумма, получатель или возврат не соответствуют интерфейсу.
- **Опасный порядок:** равные или близкие сроки мешают взыскать выше после оплаты ниже по маршруту.
- **Ошибка границы:** высота, время блока, timestamp, относительный возраст и сравнения `<` и `<=` не равнозначны.
- **Нет автоматики:** созревание лишь разрешает трату; кошелёк, узел, пользователь или наблюдатель должны действовать.
- **Комиссия и пыль:** взыскание может быть невыгодным, отсечённым, застрять или требовать нативный актив комиссии.
- **Подтверждение и реорганизация:** видимость транзакции или прообраза не означает необратимый расчёт.
- **Гонка и перегрузка:** успех, тайм-аут, замена, конфликт или задержка расходуют резерв.
- **Реализация:** ошибки скрипта, контракта, кошелька, подписи, nonce, RPC или клиента могут разрушить пути.
- **Мониторинг:** офлайн-участник может пропустить раскрытие, срок, принудительное закрытие, замену или последний момент отправки.
- **Приватность:** повторные хеши, прообразы, суммы, время и события канала помогают связывать переводы.
- **Опциональность и блокировка:** сторона может заморозить ликвидность и отказаться; завершение и компенсация не гарантированы.

До риска ценностью проверьте оба пути на ничтожной сумме, запишите артефакты и сроки, держите комиссии и назначьте ответственных за мониторинг и отправку при сбое.

<a id="misconceptions"></a>

## Распространённые заблуждения

- **«Средства вернутся автоматически после срока».** Обычно возврат лишь становится допустимым; его надо отправить и подтвердить.
- **«Условие `H(x) = h` — весь контракт».** Важны также подписи, ветви, поля, правила сети, отзыв и полномочия.
- **«Одинаковые сроки справедливы».** Посреднику или второму участнику нужен запас выше по маршруту после получения `x`.
- **«Видимый прообраз гарантирует время».** Подтверждения, реорганизация, перегрузка, комиссии и цензура могут его исчерпать.
- **«Атомарность означает изменение двух сетей одной неделимой транзакцией».** Координируются отдельные состояния; остаются отмена, возврат и временная односторонность.
- **«HTLC анонимен и устраняет всё доверие».** Он раскрывает сигналы и зависит от кода, сетей, ключей, мониторинга и эксплуатации.

<a id="related"></a>

## Связанные темы

- [Криптографический хеш](/ru/crypto/cryptographic-hash/)
- [MPC-кошелёк](/ru/crypto/mpc-wallet/)
- [Риск модуля мультиподписи](/ru/crypto/multisig-module-risk/)
- [Смарт-контракт](/ru/crypto/smart-contract/)
- [Каналы состояния](/ru/crypto/state-channels/)

<a id="sources"></a>

## Источники

- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
- [BOLT #2: протокол узлов для каналов](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs (дата обращения: 2026-08-20)
- [BOLT #3: форматы транзакций и скриптов Bitcoin](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs (дата обращения: 2026-08-20)
- [BOLT #4: протокол луковой маршрутизации](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs (дата обращения: 2026-08-20)

Source: https://wiki.fcontext.com/ru/crypto/htlc/index.mdx