라이트닝 채널의 각 상태에는 Alice가 게시할 수 있는 local commitment와 Bob이 게시할 수 있는 local commitment가 따로 있습니다. 각 거래는 동일한 채널 잔액을 반영하지만 게시자 쪽 to_local 출력에는 CSV 지연과 revocation 경로가, 상대 쪽 to_remote에는 즉시 지출 경로가 배치됩니다. 새 상태의 서명을 교환한 뒤 revoke_and_ack로 이전 per-commitment secret을 공개하면 이전 상태를 게시한 당사자의 지연 출력을 상대가 revocation key로 가져갈 수 있어 오래된 상태 방송을 억제합니다.
한 채널 상태에는 각자의 local commitment를 보유합니다
Funding output은 2-of-2 조건으로 잠기지만, 매 결제마다 체인 거래를 만들지는 않습니다. 대신 Alice와 Bob은 현재 잔액·HTLC를 반영한 서로 다른 commitment transaction에 상대의 서명을 받아 보관합니다. 연결이 끊겨도 각자는 자신이 가진 거래를 단독으로 방송해 정산을 시작할 수 있습니다.
두 거래의 경제적 합계는 같아도 script 배치는 비대칭입니다. 게시자의 to_local 출력은 상대가 revocation key로 즉시 쓰거나 게시자가 to_self_delay 뒤에 쓰는 조건이고, 상대의 to_remote 출력은 일반적으로 즉시 지출 가능합니다. 이 지연 구간이 오래된 상태를 적발해 대응할 시간을 만듭니다.
커밋먼트 거래는 잔액 영수증이면서, 상대가 사라졌을 때 각자 꺼내 쓸 수 있는 미리 서명된 비상 정산 거래입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 한 채널 상태에는 각자의 local commitment를 보유합니다
Funding output은 2-of-2 조건으로 잠기지만, 매 결제마다 체인 거래를 만들지는 않습니다.
- 출력은 잔액과 HTLC 역할에 따라 갈립니다
BOLT 3 형식은 to_local, to_remote, offered HTLC와 received HTLC 출력을 정의합니다.
- 상태 전환은 서명과 폐기를 교차시킵니다
예를 들어 상태 N에서 Alice가 20,000 msat HTLC를 추가하면 양쪽은 update_add_htlc를 반영합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
출력은 잔액과 HTLC 역할에 따라 갈립니다
BOLT 3 형식은 to_local, to_remote, offered HTLC와 received HTLC 출력을 정의합니다. HTLC output은 preimage 또는 timeout 조건에 따라 second-stage HTLC-success·HTLC-timeout transaction으로 이어질 수 있습니다. Dust 임계값 아래의 HTLC는 commitment output에서 trim되어 별도 second stage를 만들지 않습니다.
Anchor outputs 기능을 협상한 채널은 수수료 범핑을 돕는 작은 anchor를 포함할 수 있습니다. Zero-fee HTLC transaction이나 newer channel type은 feature negotiation에 따라 형식이 달라지므로, 모든 채널에 동일한 tx graph를 가정해서는 안 됩니다. 실제 channel_type과 commitment format을 먼저 확인해야 합니다.
| 출력 | 정상 상태에서의 역할 | 주요 시간 조건 |
|---|---|---|
| to_local | 게시자 잔액 | 게시자는 to_self_delay 뒤 지출 |
| to_remote | 상대 잔액 | 상대가 통상 즉시 지출 |
| offered HTLC | 내가 제안한 미결 지급 | 상대 preimage 또는 내 timeout 경로 |
| received HTLC | 내가 받은 미결 지급 | 내 preimage 또는 상대 timeout 경로 |
| anchor | CPFP fee bump 입력 | 협상된 anchor channel type에만 존재 |
상태 전환은 서명과 폐기를 교차시킵니다
예를 들어 상태 N에서 Alice가 20,000 msat HTLC를 추가하면 양쪽은 update_add_htlc를 반영합니다. Alice가 commitment_signed를 보내면 Bob은 자신의 새 commitment를 완성할 서명을 얻습니다. Bob은 revoke_and_ack로 자신의 상태 N-1 secret을 넘기고 다음 per_commitment_point를 제공한 뒤 반대 방향 서명 교환을 이어갑니다.
핵심 순서는 상대가 새 유효 상태를 확보하기 전에 이전 상태를 먼저 폐기하지 않는 것입니다. 메시지 재연결 시 양쪽 commitment number가 어긋나면 channel_reestablish로 어느 서명·revocation을 다시 보내야 하는지 판단합니다. 구현은 디스크에 서명과 secret을 원자적으로 저장하지 않으면 crash 뒤 이미 폐기한 상태만 남길 수 있습니다.
- Update 메시지를 임시 상태에 적용합니다.
- 상대 commitment용 서명과 HTLC signatures를 보냅니다.
- 수신자는 새 거래를 영구 저장한 뒤 이전 상태를 폐기합니다.
- revoke_and_ack로 이전 secret과 다음 point를 교환합니다.
- 반대 방향 commitment_signed까지 끝나면 양쪽 상태가 동기화됩니다.
오래된 상태 방송은 breach가 됩니다
Alice가 이미 폐기한 commitment를 방송하면 Bob은 공개받은 per-commitment secret으로 revocation private key를 유도할 수 있습니다. BOLT 5의 on-chain 처리에 따라 Bob은 Alice의 지연 출력과 해당 HTLC 경로를 penalty transaction으로 회수해야 합니다. 이때 to_self_delay 안에 breach를 발견하고 필요한 거래를 전파해야 합니다.
모든 일방 폐쇄가 부정행위는 아닙니다. 최신 commitment를 게시한 정상 unilateral close에서는 게시자가 CSV 지연 뒤 자기 출력을 쓰고 HTLC를 성공 또는 timeout 조건으로 정리합니다. Explorer에서 commitment가 보였다는 이유만으로 breach라고 단정하지 말고 commitment number, revocation 가능 여부와 현재 상태를 대조합니다.
복구 자료와 감시 체계를 함께 설계합니다
Static channel backup은 peer·funding 정보를 이용한 복구 협상을 돕지만, 모든 최신 commitment secret과 즉시 송금 가능 상태를 복원하는 일반 지갑 seed와 같지 않습니다. 구현별 backup semantics를 확인하고 active channel database를 일관된 방식으로 보존해야 합니다.
상시 online node가 어려우면 watchtower에 폐기 상태 대응 자료를 위탁할 수 있습니다. 그래도 tower 등록 성공, 새 상태 upload, 세션 한도와 tower 가용성을 모니터링해야 합니다. 폐기 전 영구 저장, 재연결 검증, on-chain 감시가 하나의 안전 흐름입니다.
자주 묻는 질문
왜 commitment transaction이 한 장이 아닌가요?
각 참여자가 상대 협조 없이 폐쇄할 수 있어야 하므로 같은 상태를 반영한 각자의 local commitment를 보유합니다.
revoke_and_ack를 보내면 현재 상태도 폐기되나요?
아닙니다. 새 commitment를 안전하게 확보한 뒤 이전 commitment의 secret을 공개해 그 이전 상태만 폐기합니다.
최신 commitment를 방송해도 벌금을 내나요?
최신 유효 상태의 일방 폐쇄는 정상 경로이며 revocation penalty 대상이 아닙니다. 다만 CSV 지연과 HTLC 정산 비용은 발생합니다.
Seed만 있으면 채널을 완전히 복구할 수 있나요?
일반적으로 seed만으로 최신 off-chain 상태 전체를 재구성할 수 없습니다. 사용 구현의 channel database와 backup·recovery 절차가 필요합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
