교육 목적일 뿐 투자, 법률 또는 보안 조언이 아닙니다. HTLC의 안전성은 실제 스크립트나 계약, 체인 규칙, 확인 정책, 수수료, 모니터링 및 적시 대응에 달려 있습니다.
직접 답변
해시 시간 잠금 계약(HTLC)은 서로 경쟁하는 두 지출 경로를 가진 조건부 지급입니다. 만료 전에는 수취인이 커밋된 값 h = H(x)와 해시가 일치하는 값 x를 공개하고 필요한 서명이나 권한을 충족해 청구할 수 있습니다. 만료 후에는 지급인이 환불 경로를 사용할 수 있습니다. 경계 시점의 정확한 순서는 자연어의 “이전”이 아니라 체인과 계약이 결정합니다.
해시 잠금은 동작을 연결합니다. 참여자가 하류 지급을 마친 뒤 같은 프리이미지를 알게 되면 관련 상류 지급을 정산할 수 있습니다. 시간 잠금은 자금이 조건부로 남는 기간을 제한합니다. 결제 채널 프로토콜은 이 성질로 지급을 전달하고, 아토믹 스왑 프로토콜은 서로 다른 시스템의 이전을 조정할 수 있습니다.
HTLC가 자동으로 무신뢰성, 원자성, 프라이버시 또는 자동 실행을 제공하지는 않습니다. 안전하려면 올바른 스크립트나 계약, 호환되는 해시와 프리이미지 인코딩, 엇갈린 만료, 최종성 가정, 수수료 접근성, 지속적인 모니터링, 마감 전 확인도 필요합니다. Lightning의 HTLC는 명세화된 Bitcoin 설계 중 하나이며, 다른 체인의 계약은 의미가 크게 다를 수 있습니다.
- 해시 분기: 해당 경로가 유효한 동안 필요한 프리이미지를 공개하고 성공 경로 권한을 충족합니다.
- 시간 초과 분기: 적용되는 절대 또는 상대 잠금이 만료된 뒤 환불 경로 권한을 충족합니다.
작동 방식
단일 조건부 지급에서 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 채널 구현이 아닙니다.
예시
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의 차이는 대응 여유이지 보편적으로 안전한 설정이 아닙니다. 재구성, 블록 시간 변동, 최종성, 계약 실행, 릴레이 가정, 멤풀 정책, 수수료 급등, 검열 및 운영 지연을 두 시스템 모두에서 모델링해야 합니다. 두 번째 행동자는 화면에 “확인됨”이 표시됐다는 이유만으로 진행하면 안 됩니다.
위험
- 잘못된 커밋: 두 구간의 해시 알고리즘, 프리이미지 길이 또는 인코딩이 달라 같은
x가 양쪽을 모두 만족하지 못합니다. - 잘못된 산출물: 자금이 들어간 출력, 체인 ID, 계약 주소, 바이트코드, 자산, 금액, 수취인 또는 환불 목적지가 화면 설명과 다릅니다.
- 위험한 만료 순서: 마감이 같거나 간격이 부족하면 중개자나 스왑 상대방이 하류에 지급한 뒤 상류에서 청구하지 못합니다.
- 경계 오류: 블록 높이, 블록 시간, 타임스탬프, 상대 경과 시간과
<,<=같은 비교는 의미가 같지 않습니다. - 자동 환불 없음: 만료는 지출을 유효하게 만들 뿐이며 지갑, 노드, 사용자 또는 감시 서비스가 행동해야 합니다.
- 수수료와 더스트 실패: 청구가 비경제적이거나 Lightning 커밋먼트에서 제거되고, 낮은 수수료로 정체되거나 네이티브 수수료 자산이 없어 불가능할 수 있습니다.
- 확인과 재구성 위험: 거래나 프리이미지가 보인다고 어느 체인에서든 정산이 비가역적인 것은 아닙니다.
- 경쟁과 혼잡 위험: 성공 지출, 시간 초과 지출, 대체, 충돌 또는 악의적 지연이 대응 시간을 소진할 수 있습니다.
- 구현 위험: 스크립트, 스마트 계약, 지갑, 서명, nonce, RPC 또는 클라이언트 결함이 의도한 경로를 무효화할 수 있습니다.
- 모니터링 위험: 오프라인 참여자는 공개, 만료, 강제 종료, 대체 또는 실질적인 마지막 방송 시점을 놓칠 수 있습니다.
- 프라이버시 누출: 재사용된 지급 해시, 공개 프리이미지, 금액, 시각과 채널 사건이 이전이나 경로를 연관하는 데 쓰일 수 있습니다.
- 선택권과 방해: 한쪽이 상대 유동성을 잠근 뒤 중단할 수 있으며, 조건부 정산은 완료나 지연 보상을 보장하지 않습니다.
가치를 위험에 놓기 전에 무시할 만한 금액으로 성공과 환불 경로를 모두 시험하고, 정확한 산출물과 마감을 기록하며, 수수료를 확보하고 장애 시 감시와 방송 책임자를 정해야 합니다.
흔한 오해
- “시간이 끝나면 자금이 자동 환불된다.” 보통은 환불 지출이 가능해질 뿐이며 누군가 방송하고 확인받아야 합니다.
- “
H(x) = h일치가 계약의 전부다.” 서명, 스크립트 분기, 거래 필드, 체인 규칙, 폐기 로직 및 계약 권한도 중요합니다. - “양쪽 만료를 같게 하는 것이 공정하다.” 전달 노드나 두 번째 행동자는
x를 안 뒤 의도적인 상류 여유가 필요합니다. - “프리이미지가 보이면 청구할 시간이 보장된다.” 확인 지연, 재구성, 혼잡, 수수료 및 검열이 남은 시간을 소진할 수 있습니다.
- “원자적이라는 것은 두 체인이 하나의 불가분 거래로 바뀐다는 뜻이다.” 크로스체인 스왑은 분리된 상태 전이를 조정하며 중단과 환불 경로, 일시적인 단방향 상태가 남습니다.
- “HTLC는 익명이고 모든 신뢰를 없앤다.” 상관 신호를 노출할 수 있고 프로토콜 코드, 체인 동작, 키, 모니터링 및 운영 가정에 의존합니다.
관련 주제
출처
- BIP 65: OP_CHECKLOCKTIMEVERIFY - Bitcoin Improvement Proposals (열람일: 2026-08-20)
- BIP 112: CHECKSEQUENCEVERIFY - Bitcoin Improvement Proposals (열람일: 2026-08-20)
- BOLT #2: 채널 관리 피어 프로토콜 - Lightning BOLTs (열람일: 2026-08-20)
- BOLT #3: Bitcoin 거래 및 스크립트 형식 - Lightning BOLTs (열람일: 2026-08-20)
- BOLT #4: 어니언 라우팅 프로토콜 - Lightning BOLTs (열람일: 2026-08-20)