라이트닝 여러 홉 결제에서는 채널마다 같은 결제 해시(payment hash)에 묶인 들어오는 HTLC와 나가는 HTLC가 추가됩니다. 수신자가 프리이미지(preimage)를 공개하면 마지막 홉부터 거꾸로, 중간 노드가 나가는 HTLC를 청구하고 그 프리이미지로 들어오는 HTLC를 청구합니다. 프리이미지가 끝내 나오지 않으면 만료 뒤 시간 초과로 끝납니다. 앞쪽 만료는 뒤쪽보다 길고, 들어오는 금액은 전달 수수료만큼 커야 합니다. 그래야 중간 노드가 뒤쪽에 지급하고도 앞쪽에서 돈을 회수할 시간과 금액을 확보합니다.
해시 잠금이 지급 조건을 하나로 잇습니다
수신자는 32바이트 결제 프리이미지 R을 만들고 H=SHA256(R)을 인보이스에 넣습니다. 송신자가 만든 update_add_htlc에는 amount_msat, payment_hash H, cltv_expiry와 어니언 패킷이 담깁니다. 중간 노드는 R을 모르므로 조건 없이 나가는 자금을 가져갈 수 없습니다.
수신자가 올바른 R을 내놓으면 홉마다 SHA256(R)=H인지 확인합니다. update_fulfill_htlc가 거꾸로 퍼지면서 R은 되돌릴 수 없는 지식이 됩니다. BOLT2는 나가는 쪽에서 이행(fulfill) 메시지를 받은 노드가 짝이 되는 들어오는 HTLC도 이행해야 한다고 정합니다.
HTLC의 원자성은 한 번 공개된 같은 프리이미지가 경로 전체의 청구 조건을 한꺼번에 풀어 주는 데서 나옵니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 해시 잠금이 지급 조건을 하나로 잇습니다
수신자는 32바이트 결제 프리이미지 R을 만들고 H=SHA256(R)을 인보이스에 넣습니다.
- 시간 잠금은 홉마다 계단처럼 줄어듭니다
A→B→C 경로에서 B가 C에게 건 HTLC의 만료는 A에게서 받은 HTLC의 만료보다 이릅니다.
- 약정 거래에 반영되기 전에는 넘기지 않습니다
메시지를 받았다고 채널 상태가 확정된 것은 아닙니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
시간 잠금은 홉마다 계단처럼 줄어듭니다
A→B→C 경로에서 B가 C에게 건 HTLC의 만료는 A에게서 받은 HTLC의 만료보다 이릅니다. C가 마지막 순간에 온체인으로 R을 공개하더라도, B가 그것을 보고 A 쪽 HTLC를 청구할 시간이 남아 있어야 합니다. 그 차이에는 B가 나가는 채널에 광고한 cltv_expiry_delta가 반영됩니다.
BOLT2는 들어오는 만료와 현재 블록 높이의 차이가 나가는 쪽 델타보다 작으면 전달하지 말라고 요구합니다. 수신자도 min_final_cltv_expiry_delta를 요구합니다. 블록 간격, 재편성, 온체인 확인 지연이 있으므로 단순히 벽시계 초 단위로 바꾸지 않습니다.
| 항목 | 들어오는 쪽 A→B | 나가는 쪽 B→C |
|---|---|---|
| 결제 해시 | H | 같은 H |
| 금액 | 더 큼 | 수수료를 뺀 금액 |
| 만료 | 더 늦음 | 더 이름 |
| 성공 조건 | R로 청구 | R로 지급 |
| 시간 초과 | A가 환불 가능 | B가 환불 가능 |
약정 거래에 반영되기 전에는 넘기지 않습니다
메시지를 받았다고 채널 상태가 확정된 것은 아닙니다. HTLC 추가는 양쪽 약정 거래(commitment transaction)에 반영되고, 이전 상태를 폐기하는 갱신 절차를 거친 뒤에야 되돌릴 수 없게 확정됩니다. BOLT2는 들어오는 HTLC가 확정되기 전에 짝이 되는 나가는 HTLC를 제안하지 말라고 합니다.
이 순서를 어기면 중간 노드가 앞쪽에서 받을 권리를 확보하기도 전에 뒤쪽에 돈을 내줄 수 있습니다. 구현체는 update_add_htlc, commitment_signed, revoke_and_ack 상태를 채널별로 저장해 두고, 비정상 종료 뒤 복구할 때 이행이나 실패 처리가 두 번 일어나지 않게 막습니다.
- 인보이스의 결제 해시·금액·만료를 확인합니다.
- 경로의 홉마다 수수료와 CLTV 델타를 더해 갑니다.
- 들어오는 HTLC가 약정 거래에 확정될 때까지 기다립니다.
- 어니언 페이로드대로 나가는 HTLC를 제안합니다.
- 프리이미지나 시간 초과를 거꾸로 정산합니다.
온체인 전환은 원자성을 강제하는 마지막 수단입니다
상대 노드가 응답하지 않으면 최신 약정 거래를 브로드캐스트하고 HTLC 성공 경로나 시간 초과 경로를 씁니다. 프리이미지가 체인의 증인 데이터에 드러나면 앞쪽 노드도 그 값을 꺼내 청구할 수 있습니다. 마감 전에 거래가 충분히 확인되도록 넉넉한 수수료와 안전 여유가 필요합니다.
작은 HTLC는 약정 거래에서 더스트(dust)로 잘려 별도 출력이 없을 수 있습니다. 강제 종료 때 채굴 수수료로 사라질 노출 금액은 max_dust_htlc_exposure_msat 같은 로컬 정책으로 제한합니다. 모든 HTLC가 독립된 온체인 출력으로 보장된다고 설명하지 않습니다.
결제 실패는 어떤 조건에서 막혔는지 나눠 봅니다
일시적 채널 장애, 유동성 부족, 수수료나 CLTV 불일치, 잘못된 어니언, 너무 이른 만료는 재시도할 때의 의미가 저마다 다릅니다. 송신자는 암호화된 실패 메시지를 풀어 실패한 홉을 짐작하고 경로를 바꿉니다. 다만 탐침을 되풀이하면 프라이버시가 새어 나갈 수 있습니다.
다중 경로 결제(MPP)는 같은 결제 비밀과 총액 조건 아래 여러 HTLC 조각을 모을 수 있습니다. 하지만 조각마다 성공인지 시간 초과인지를 따로 추적해야 합니다. 화면에는 결제 대기·성공·실패와 개별 시도를 구분해 보여 주고, 인보이스가 만료됐다고 이미 확정된 HTLC까지 곧바로 취소된 것으로 처리하지 않습니다.
자주 묻는 질문
중간 노드는 수신자의 프리이미지를 미리 아나요?
아닙니다. 수신자가 이행할 때 공개되고, 그 뒤 거꾸로 전달됩니다.
모든 홉의 CLTV 만료가 같아도 되나요?
안 됩니다. 중간 노드가 뒤쪽에서 청구된 뒤 앞쪽에서 회수할 만큼의 안전한 델타가 필요합니다.
HTLC는 언제나 온체인 출력으로 남나요?
작은 HTLC는 더스트 기준과 수수료에 따라 약정 거래에서 잘려 나갈 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
