HTLC는 Hashed Timelock Contract의 약자입니다. 한 경로에서는 해시를 계산했을 때 미리 알려진 값(디지털 지문)과 일치하는 비밀값이 필요하고, 다른 경로에서는 시간 조건을 충족한 뒤 자금을 회수할 수 있는 조건부 결제입니다. 이 비밀값을 preimage라고 부릅니다. 지갑 비밀번호는 아닙니다. 값을 안다고 필요한 서명을 대신할 수는 없으며, 시간이 지났다고 돈이 자동으로 돌아오지도 않습니다.
안나는 Lightning Network로 파벨에게 20,000 sat를 보내려고 합니다. Sat는 satoshi의 약자로, 비트코인 체인에서 사용하는 가장 작은 단위입니다. 둘 사이에 직접 결제 채널은 없지만, 에바를 통해 적절하게 연결되어 있습니다. 채널은 두 참여자의 비트코인 배분에 관한 합의로, 결제할 때마다 새 트랜잭션을 블록에 기록하지 않고 갱신할 수 있습니다. 에바는 파벨에게 조건부로 20,000 sat를 제안하고, 안나는 에바에게 20,010 sat를 제안합니다. 이 단순화한 예시에서는 차액 10 sat가 에바의 수수료입니다. 두 채널의 잔액 변화가 연결되는 것이지, 동일한 특정 동전 하나가 두 채널을 통과하는 것은 아닙니다. 파벨은 자신의 조건을 충족할 비밀을 알고 있고, 에바는 같은 값을 안나에게 사용할 수 있습니다. 파벨의 약속만 믿고 먼저 되돌릴 수 없는 결제를 할 필요가 없습니다. 이 금액은 원리 설명용이며 일반적이거나 권장되는 수수료가 아닙니다. [1]
파벨은 결제용으로 32바이트의 무작위 비밀값 payment_preimage를 준비합니다. SHA-256은 여기서 payment_hash를 계산합니다. 공개된 값이 올바른 지문을 만드는지 확인하기는 쉽지만, 제대로 선택한 비밀을 지문만으로 알아내는 것은 현실적으로 불가능합니다. 일반적인 BOLT 11 인보이스, 즉 Lightning 결제 요청에는 p 필드에 해시가 들어 있고 preimage 자체는 없습니다. 파벨이 결제 조건을 충족하면 비밀이 경로를 거슬러 전달되어 해당 HTLC들을 연결합니다. s 필드의 payment_secret은 별개의 값입니다. 수신자가 결제를 올바르게 처리하도록 돕지만 preimage를 대신하지는 못합니다. 이 값들은 Seed Phrase(지갑 복구에 쓰는 단어들)나 지갑 개인 키가 아닙니다. [1] [4]
두 결제의 기한이 같다면 파벨이 너무 늦게 비밀을 공개해 에바가 수신 결제를 확보하지 못할 수 있습니다. 따라서 안나에게서 들어오는 HTLC는 에바가 파벨에게 보내는 HTLC보다 늦게 만료됩니다. cltv_expiry_delta라는 차이가 에바에게 여유를 줍니다. 상대방이 응답을 멈추고 비트코인 온체인 트랜잭션으로 합의를 실행해야 할 때도 이 여유가 필요합니다. 여유는 정확한 분 수가 아니라 블록 수로 계산하며 지연과 체인 재구성도 고려해야 합니다. 안전한 설정은 소프트웨어와 채널 규칙에 따릅니다. 여유가 너무 작으면 자금이 위험해집니다. 체인 재구성은 체인의 일부가 다른 유효한 분기로 교체되는 일이며, 이로 인해 이전 거래의 확인 상태가 달라질 수 있습니다. [1]
Lightning의 cltv_expiry는 블록 높이, 즉 체인에서 블록의 위치입니다. Unix timestamp(날짜와 시각을 초 수로 나타낸 값)나 초 단위 BOLT 11 인보이스 유효기간이 아닙니다. 시간 조건을 충족하면 비밀 없이 정산하는 timeout 경로가 열릴 수 있습니다. 자금은 스스로 이동하지 않습니다. 결제 채널을 관리하는 프로그램인 Lightning 노드가 채널 갱신을 제대로 완료하거나 해당 온체인 트랜잭션을 사용해야 합니다. 유효한 preimage도 기한이 됐다고 자동으로 작동을 멈추지는 않습니다. 같은 출력(지출 규칙이 붙은 금액)이 다른 방식으로 이미 소비되지 않았다면 허용된 경로들이 경쟁할 수 있으나, 두 지출이 하나의 유효한 체인에서 모두 확인될 수는 없습니다. 따라서 제때 대응하는 것도 안전성의 일부입니다. [1] [4] [5]
HTLC는 조건을 연결할 뿐, 어떤 금액이든 어떤 경로로든 통과시키지는 못합니다. 에바에게는 발신 방향의 충분한 자금, 즉 유동성과 대기 HTLC 하나를 더 처리할 여유가 필요합니다. 한도, 수수료 또는 연결할 수 없는 노드 때문에 결제가 멈출 수 있습니다. 대기 중인 시도가 올바르게 해결되기 전까지 일부 자금이 묶일 수도 있습니다. 지갑 상태는 전체 시도를 설명하며 메시지 하나만으로 결과를 판단할 수는 없습니다. preimage 공개는 비트코인 트랜잭션 확인과 다릅니다. 일반적으로 성공한 Lightning 결제는 채널 갱신으로 정산되며 각 결제를 새 블록에 기록하지 않습니다. [1] [3]
다음 부분은 기술 참고 자료입니다. 채널 상태는 각 금액의 권리자와 아직 대기 중인 HTLC를 기록합니다. Commitment transaction은 그 상태를 온체인에서 실행할 수 있는 서명된 비트코인 트랜잭션입니다. update_add_htlc는 추가를 제안하고, update_fulfill_htlc는 이행을, update_fail_htlc는 실패를 알립니다. 변경을 알리는 것만으로는 부족합니다. 양측은 commitment_signed와 revoke_and_ack를 통해 새 상태의 서명과 이전 상태의 사용을 위험하게 만드는 정보를 교환합니다. BOLT 2에 따라 양측이 해당 변경에 철회 불가능하게 합의해야 다음 의무가 그 변경을 기반으로 할 수 있습니다. 참여자 사이의 합의는 블록 확인이 아닙니다. 반면 채널 자금 조달과 필요할 때의 폐쇄는 비트코인 트랜잭션에 기반합니다. [1]
필드는 메시지의 개별 데이터입니다. Millisatoshi는 satoshi의 천분의 일로 Lightning 내부 회계 단위입니다. 비트코인 체인에서 이 작은 단위를 별도로 소비할 수는 없습니다. update_add_htlc 메시지의 기본 필드는 channel_id, id, amount_msat, payment_hash, cltv_expiry, onion_routing_packet입니다. amount_msat의 단위는 millisatoshi입니다. 노드는 채널 한도, 가용 유동성, 전달 조건을 확인하고 발신 HTLC는 자체 매개변수를 갖습니다. BOLT 2에 따라 수신 HTLC 추가가 철회 불가능하게 확약되기 전에는 대응하는 발신 HTLC를 제안해서는 안 됩니다. [1]
Onion routing은 각 중개자의 지시를 서로 다른 암호화 계층으로 감쌉니다. 에바는 모든 참여자의 공개 목록이 아니라 자기 단계에 필요한 정보를 받습니다. 노드는 자기 onion 계층을 복호화하고 무결성을 검증합니다. 일반적인 비블라인드 경로에서는 amt_to_forward와 outgoing_cltv_value를 수신 금액, 수수료, 필요한 시간 차이와 비교합니다. 패킷은 전체 경로를 노드에 공개하지 않습니다. 그러나 트래픽 상관관계 분석이나 다른 신원 추론을 배제하지는 않습니다. onion routing은 절대적인 익명성을 보장하지 않습니다. [3]
출력은 Script라는 언어로 작성한 지출 규칙이 붙은 금액입니다. Offered와 received는 채널 참여자 관점에서 제안한 HTLC와 받은 HTLC를 뜻합니다. 2단계는 후속 트랜잭션이며 CHECKSEQUENCEVERIFY(CSV)는 사용하는 출력의 확인을 기준으로 한 대기 시간을 요구합니다. 폐기 키는 이미 폐기된 옛 상태를 공개했을 때 페널티를 적용하는 데 쓰입니다. BOLT 3은 offered와 received 출력 및 HTLC-success나 HTLC-timeout 경로를 구분합니다. 단순히 해시를 아는 것으로는 부족하며 해당 서명, preimage, 시간 조건이 적용됩니다. 로컬 2단계 출력에는 to_self_delay의 CSV 지연이 있지만, 올바른 폐기 키를 가진 상대방은 그 지연 없이 페널티 분기를 사용할 수 있습니다. 정확한 Script는 채널 유형에 따라 달라집니다. [2] [6]
Trimming은 채널 상태를 온체인으로 옮길 때 작은 HTLC가 독립 출력이 되지 않는다는 뜻입니다. Dust는 그런 작은 금액을 가리킵니다. Dust exposure는 이 제한에 노출되는 총액을 나타냅니다. 적용되는 2단계 수수료를 뺀 금액이 dust_limit_satoshis보다 작으면 커밋먼트 트랜잭션은 HTLC 출력을 만들지 않습니다. 규칙은 협상된 유형에 따라 다릅니다. option_anchors와 zero_fee_commitments에는 해당 2단계 수수료가 없으며, zero_fee_commitments는 잘린 금액을 shared_anchor로 보낼 수 있습니다. 없는 출력을 온체인에서 별도로 청구할 수는 없습니다. 이러한 HTLC의 합계가 dust exposure입니다. [2] [1]
다음 검사는 노드 운영자와 개발자용입니다. 디코딩은 기록을 읽을 수 있는 필드로 바꾸며, 아무것도 전송하지 않고 모든 조건 충족을 증명하지도 않습니다. 수신 및 발신 amount_msat, payment_hash, cltv_expiry를 비교하고 SHA-256으로 preimage를 검증하세요. fulfill/fail 메시지 하나만이 아니라 commitment_signed, revoke_and_ack 및 최종 상태도 추적하세요. 온체인 집행 시 실제 커밋먼트 트랜잭션을 디코딩하고 출력 존재 여부, 사용 분기, HTLC-success/HTLC-timeout을 확인하세요. 서명, 시간 조건, 확인 여부도 확인해야 하며 디코딩만으로 유효성이 증명되지는 않습니다. [1] [2]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Lightning Network, Payment Channel, Timelock, Hash, CLTV, CSV. 다음 항목에서도 이 글을 참조합니다 Timelock, Payment Channel, Lightning 유동성, Lightning Routing.