---
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)은 서로 경쟁하는 두 지출 경로를 가진 조건부 지급입니다. 만료 전에는 수취인이 커밋된 값 `h = H(x)`와 해시가 일치하는 값 `x`를 공개하고 필요한 서명이나 권한을 충족해 청구할 수 있습니다. 만료 후에는 지급인이 환불 경로를 사용할 수 있습니다. 경계 시점의 정확한 순서는 자연어의 "이전"이 아니라 체인과 계약이 결정합니다.

해시 잠금은 동작을 연결합니다. 참여자가 하류 지급을 마친 뒤 같은 프리이미지를 알게 되면 관련 상류 지급을 정산할 수 있습니다. 시간 잠금은 자금이 조건부로 남는 기간을 제한합니다. 결제 채널 프로토콜은 이 성질로 지급을 전달하고, 아토믹 스왑 프로토콜은 서로 다른 시스템의 이전을 조정할 수 있습니다.

HTLC가 자동으로 무신뢰성, 원자성, 프라이버시 또는 자동 실행을 제공하지는 않습니다. 안전하려면 올바른 스크립트나 계약, 호환되는 해시와 프리이미지 인코딩, 엇갈린 만료, 최종성 가정, 수수료 접근성, 지속적인 모니터링, 마감 전 확인도 필요합니다. Lightning의 HTLC는 명세화된 Bitcoin 설계 중 하나이며, 다른 체인의 계약은 의미가 크게 다를 수 있습니다.

- **해시 분기:** 해당 경로가 유효한 동안 필요한 프리이미지를 공개하고 성공 경로 권한을 충족합니다.
- **시간 초과 분기:** 적용되는 절대 또는 상대 잠금이 만료된 뒤 환불 경로 권한을 충족합니다.

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

## 작동 방식

단일 조건부 지급에서 Bob이 새롭고 예측 불가능한 프리이미지 `x`를 고르고 `h = H(x)`를 계산해 `h`를 Alice에게 준다고 가정합니다. Alice는 `h`를 커밋하고 권한 보유자를 식별하며 만료 `T`를 정하는 규칙으로 자금을 잠급니다.

- Alice는 자금 제공 전에 해시 알고리즘, 바이트 인코딩, 금액, 자산, 수취인, 환불 목적지, 체인 및 만료를 확인합니다.
- Bob은 거래 초안이나 화면 표시를 믿지 않고 실제 자금이 들어간 출력 또는 배포된 계약을 확인합니다.
- Bob이 성공 분기로 청구하면 `x`를 제공하며, 지출 로직은 `H(x) = h`와 필요한 권한을 검사합니다.
- `x`가 체인에 공개되거나 프로토콜로 전달되면 Alice 또는 중개자가 같은 지급 해시를 가진 다른 HTLC를 정산할 수 있습니다.
- 성공 분기를 제때 쓰지 않으면 환불 분기가 `T`에 사용 가능해지지만, 이것만으로 환불이 방송되거나 확인되지는 않습니다.
- 참여자는 올바른 거래를 만들거나 보관하고 충분한 수수료를 지불해 제출하며, 대체와 충돌을 감시하고 필요한 확인 깊이를 얻어야 합니다.
- `x`를 상대방이나 공개 체인에 보여준 뒤에는 공개된 것으로 취급하고 무관한 조건에 재사용하지 않아야 합니다.

Bitcoin은 절대 잠금과 상대 잠금을 구분합니다. BIP 65의 `OP_CHECKLOCKTIMEVERIFY`는 거래 잠금 시간을 통해 지정 블록 높이 또는 블록 시간까지 지출을 제한하고, BIP 112의 `OP_CHECKSEQUENCEVERIFY`는 입력의 상대 경과 시간이 충분할 때까지 지출을 제한합니다. 스크립트에는 호환되는 거래 필드도 필요합니다. 따라서 시간 잠금은 검증 규칙이지 스케줄러가 아닙니다.

Lightning에서 `update_add_htlc`는 금액, `payment_hash`, `cltv_expiry`를 전달합니다. 각 전달 홉은 대응하는 수신 HTLC보다 더 일찍 만료되는 송신 HTLC를 제안해, 프리이미지를 안 뒤 상류에서 청구할 시간을 남깁니다. BOLT 3은 커밋먼트 출력, `HTLC-success`, `HTLC-timeout` 경로와 서명, 폐기 처리, 더스트 제거, 추가 지연을 정의합니다. 두 분기 개요만으로는 완전한 Lightning 채널 구현이 아닙니다.

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

## 예시

Alice가 `1 BTC`를 Bob의 `20 ETH`와 교환하는 교육용 예시를 생각해 봅시다. 이는 순서만 보여 줍니다. 실제 Bitcoin과 Ethereum 구현에는 체인별로 검토된 코드가 필요하며 이 명목 기간을 그대로 복사해서는 안 됩니다.

- Alice는 새로운 `x`와 `h = H(x)`를 만들고 Bob이 프리이미지로 청구하며 Alice가 `48 hours` 후 환불할 수 있도록 `1 BTC`를 잠급니다.
- Bob은 Bitcoin 거래와 선택한 확인 정책을 점검한 뒤 호환되는 해시와 인코딩 규칙으로 `20 ETH`를 잠급니다. Alice의 성공 경로는 `24 hours` 후 끝나고 Bob의 환불 경로가 이어집니다.
- Alice는 `x`를 공개해 `20 ETH`를 청구하기 전에 Ethereum 체인 ID, 계약 바이트코드와 주소, 토큰 또는 네이티브 자산, 금액, 당사자, `h`, 두 호출 경로를 확인합니다.
- Bob은 성공한 청구나 합의된 프로토콜 메시지에서 `x`를 알아내고 더 늦은 마감 전에 Bitcoin 성공 경로를 시도합니다.
- 공개 전에 교환이 중단되면 각 환불은 해당 체인 규칙에 따라서만 가능해지며, 각 당사자가 환불 거래를 제출하고 확인받아야 합니다.

`48 hours`와 `24 hours`의 차이는 대응 여유이지 보편적으로 안전한 설정이 아닙니다. 재구성, 블록 시간 변동, 최종성, 계약 실행, 릴레이 가정, 멤풀 정책, 수수료 급등, 검열 및 운영 지연을 두 시스템 모두에서 모델링해야 합니다. 두 번째 행동자는 화면에 "확인됨"이 표시됐다는 이유만으로 진행하면 안 됩니다.

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

## 위험

- **잘못된 커밋:** 두 구간의 해시 알고리즘, 프리이미지 길이 또는 인코딩이 달라 같은 `x`가 양쪽을 모두 만족하지 못합니다.
- **잘못된 산출물:** 자금이 들어간 출력, 체인 ID, 계약 주소, 바이트코드, 자산, 금액, 수취인 또는 환불 목적지가 화면 설명과 다릅니다.
- **위험한 만료 순서:** 마감이 같거나 간격이 부족하면 중개자나 스왑 상대방이 하류에 지급한 뒤 상류에서 청구하지 못합니다.
- **경계 오류:** 블록 높이, 블록 시간, 타임스탬프, 상대 경과 시간과 `<`, `<=` 같은 비교는 의미가 같지 않습니다.
- **자동 환불 없음:** 만료는 지출을 유효하게 만들 뿐이며 지갑, 노드, 사용자 또는 감시 서비스가 행동해야 합니다.
- **수수료와 더스트 실패:** 청구가 비경제적이거나 Lightning 커밋먼트에서 제거되고, 낮은 수수료로 정체되거나 네이티브 수수료 자산이 없어 불가능할 수 있습니다.
- **확인과 재구성 위험:** 거래나 프리이미지가 보인다고 어느 체인에서든 정산이 비가역적인 것은 아닙니다.
- **경쟁과 혼잡 위험:** 성공 지출, 시간 초과 지출, 대체, 충돌 또는 악의적 지연이 대응 시간을 소진할 수 있습니다.
- **구현 위험:** 스크립트, 스마트 계약, 지갑, 서명, nonce, RPC 또는 클라이언트 결함이 의도한 경로를 무효화할 수 있습니다.
- **모니터링 위험:** 오프라인 참여자는 공개, 만료, 강제 종료, 대체 또는 실질적인 마지막 방송 시점을 놓칠 수 있습니다.
- **프라이버시 누출:** 재사용된 지급 해시, 공개 프리이미지, 금액, 시각과 채널 사건이 이전이나 경로를 연관하는 데 쓰일 수 있습니다.
- **선택권과 방해:** 한쪽이 상대 유동성을 잠근 뒤 중단할 수 있으며, 조건부 정산은 완료나 지연 보상을 보장하지 않습니다.

가치를 위험에 놓기 전에 무시할 만한 금액으로 성공과 환불 경로를 모두 시험하고, 정확한 산출물과 마감을 기록하며, 수수료를 확보하고 장애 시 감시와 방송 책임자를 정해야 합니다.

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

## 흔한 오해

- **"시간이 끝나면 자금이 자동 환불된다."** 보통은 환불 지출이 가능해질 뿐이며 누군가 방송하고 확인받아야 합니다.
- **"`H(x) = h` 일치가 계약의 전부다."** 서명, 스크립트 분기, 거래 필드, 체인 규칙, 폐기 로직 및 계약 권한도 중요합니다.
- **"양쪽 만료를 같게 하는 것이 공정하다."** 전달 노드나 두 번째 행동자는 `x`를 안 뒤 의도적인 상류 여유가 필요합니다.
- **"프리이미지가 보이면 청구할 시간이 보장된다."** 확인 지연, 재구성, 혼잡, 수수료 및 검열이 남은 시간을 소진할 수 있습니다.
- **"원자적이라는 것은 두 체인이 하나의 불가분 거래로 바뀐다는 뜻이다."** 크로스체인 스왑은 분리된 상태 전이를 조정하며 중단과 환불 경로, 일시적인 단방향 상태가 남습니다.
- **"HTLC는 익명이고 모든 신뢰를 없앤다."** 상관 신호를 노출할 수 있고 프로토콜 코드, 체인 동작, 키, 모니터링 및 운영 가정에 의존합니다.

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

## 관련 주제

- [암호학적 해시](/ko/crypto/cryptographic-hash/)
- [MPC 지갑](/ko/crypto/mpc-wallet/)
- [다중 서명 모듈 위험](/ko/crypto/multisig-module-risk/)
- [스마트 계약](/ko/crypto/smart-contract/)
- [상태 채널](/ko/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/ko/crypto/htlc/index.mdx