라이트닝 채널의 상태 하나에는 Alice가 게시할 수 있는 커밋먼트 거래(commitment transaction)와 Bob이 게시할 수 있는 커밋먼트 거래가 따로 있습니다. 두 거래는 같은 채널 잔액을 반영하지만, 게시자 쪽 to_local 출력에는 CSV 지연과 폐기(revocation) 경로가, 상대 쪽 to_remote 출력에는 곧바로 쓸 수 있는 경로가 들어갑니다. 새 상태의 서명을 주고받은 뒤 revoke_and_ack로 이전 상태의 커밋먼트별 비밀값을 공개하면, 이전 상태를 게시한 쪽의 지연 출력을 상대가 폐기 키로 가져갈 수 있습니다. 이 장치가 오래된 상태를 방송하지 못하게 막습니다.
한 채널 상태에는 각자의 커밋먼트 거래가 있습니다
펀딩 출력은 2-of-2 조건으로 잠기지만, 결제할 때마다 체인에 거래를 올리지는 않습니다. 대신 Alice와 Bob은 현재 잔액과 HTLC를 반영한 서로 다른 커밋먼트 거래에 상대의 서명을 받아 보관합니다. 연결이 끊겨도 각자 자기가 가진 거래를 혼자 방송해 정산을 시작할 수 있습니다.
두 거래의 경제적 합계는 같아도 스크립트 배치는 비대칭입니다. 게시자의 to_local 출력은 상대가 폐기 키로 즉시 쓰거나 게시자가 to_self_delay가 지난 뒤에 쓰는 조건이고, 상대의 to_remote 출력은 보통 곧바로 쓸 수 있습니다. 이 지연 구간이 오래된 상태를 찾아내 대응할 시간을 벌어 줍니다.
커밋먼트 거래는 잔액 영수증이면서, 상대가 사라졌을 때 각자 꺼내 쓸 수 있도록 미리 서명해 둔 비상 정산 거래입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 한 채널 상태에는 각자의 커밋먼트 거래가 있습니다
펀딩 출력은 2-of-2 조건으로 잠기지만, 결제할 때마다 체인에 거래를 올리지는 않습니다.
- 출력은 잔액과 HTLC 역할에 따라 갈립니다
BOLT 3 형식은 to_local, to_remote, 내가 제안한 HTLC, 내가 받은 HTLC 출력을 정의합니다.
- 상태 전환은 서명과 폐기를 교차시킵니다
예를 들어 상태 N에서 Alice가 20,000 msat짜리 HTLC를 추가하면 양쪽은 update_add_htlc를 반영합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
출력은 잔액과 HTLC 역할에 따라 갈립니다
BOLT 3 형식은 to_local, to_remote, 내가 제안한 HTLC, 내가 받은 HTLC 출력을 정의합니다. HTLC 출력은 프리이미지나 시간 만료 조건에 따라 두 번째 단계 거래인 HTLC-success·HTLC-timeout 거래로 이어질 수 있습니다. 더스트 임계값보다 작은 HTLC는 커밋먼트 출력에서 잘려 나가 별도의 두 번째 단계 거래를 만들지 않습니다.
앵커 출력(anchor outputs) 기능을 협상한 채널에는 수수료 올리기를 돕는 작은 앵커 출력이 들어갈 수 있습니다. 수수료 없는 HTLC 거래나 더 새로운 채널 유형은 기능 협상 결과에 따라 형식이 달라지므로 모든 채널에 같은 거래 구조를 가정해서는 안 됩니다. 실제 channel_type과 커밋먼트 형식을 먼저 확인해야 합니다.
| 출력 | 정상 상태에서의 역할 | 주요 시간 조건 |
|---|---|---|
| to_local | 게시자 잔액 | 게시자는 to_self_delay 뒤 지출 |
| to_remote | 상대 잔액 | 상대가 보통 즉시 지출 |
| 제안한 HTLC | 내가 제안한 미결 지급 | 상대의 프리이미지 또는 나의 만료 경로 |
| 받은 HTLC | 내가 받은 미결 지급 | 나의 프리이미지 또는 상대의 만료 경로 |
| 앵커 | CPFP 수수료 올리기용 입력 | 앵커 채널 유형을 협상했을 때만 존재 |
상태 전환은 서명과 폐기를 교차시킵니다
예를 들어 상태 N에서 Alice가 20,000 msat짜리 HTLC를 추가하면 양쪽은 update_add_htlc를 반영합니다. Alice가 commitment_signed를 보내면 Bob은 자신의 새 커밋먼트 거래를 완성할 서명을 얻습니다. Bob은 revoke_and_ack로 자기 상태 N-1의 비밀값을 넘기고 다음 per_commitment_point를 알려 준 뒤, 반대 방향의 서명 교환을 이어 갑니다.
핵심은 상대가 새로운 유효 상태를 손에 넣기 전에 이전 상태를 먼저 폐기하지 않는 것입니다. 다시 연결했을 때 양쪽의 커밋먼트 번호가 어긋나 있으면 channel_reestablish로 어떤 서명이나 폐기 정보를 다시 보내야 하는지 판단합니다. 구현이 서명과 비밀값을 디스크에 한꺼번에 저장하지 않으면, 비정상 종료 뒤에 이미 폐기한 상태만 남을 수 있습니다.
- 갱신 메시지를 임시 상태에 적용합니다.
- 상대 커밋먼트용 서명과 HTLC 서명을 보냅니다.
- 받는 쪽은 새 거래를 영구 저장한 뒤 이전 상태를 폐기합니다.
- revoke_and_ack로 이전 비밀값과 다음 포인트를 교환합니다.
- 반대 방향 commitment_signed까지 끝나면 양쪽 상태가 맞춰집니다.
오래된 상태 방송은 위반이 됩니다
Alice가 이미 폐기한 커밋먼트 거래를 방송하면, Bob은 공개받은 커밋먼트별 비밀값으로 폐기용 개인 키를 계산해 낼 수 있습니다. BOLT 5의 온체인 처리 규칙에 따라 Bob은 Alice의 지연 출력과 해당 HTLC 경로를 벌칙 거래로 회수해야 합니다. 이때 to_self_delay 안에 위반을 발견하고 필요한 거래를 전파해야 합니다.
모든 일방 폐쇄가 부정행위는 아닙니다. 최신 커밋먼트 거래를 게시한 정상적인 일방 폐쇄라면, 게시자는 CSV 지연이 지난 뒤 자기 출력을 쓰고 HTLC는 성공 또는 만료 조건으로 정리합니다. 탐색기에 커밋먼트 거래가 보인다는 이유만으로 위반이라고 단정하지 말고, 커밋먼트 번호와 폐기 가능 여부, 현재 상태를 맞춰 봅니다.
복구 자료와 감시 체계를 함께 설계합니다
정적 채널 백업(static channel backup)은 피어와 펀딩 정보로 복구 협상을 하도록 돕습니다. 하지만 최신 커밋먼트 비밀값 전부와 바로 송금 가능한 상태까지 되살려 주는 일반 지갑 시드와는 다릅니다. 구현마다 백업이 무엇을 보장하는지 확인하고, 사용 중인 채널 데이터베이스를 일관된 방식으로 보존해야 합니다.
노드를 늘 켜 두기 어렵다면 워치타워에 폐기 상태 대응 자료를 맡길 수 있습니다. 그래도 워치타워 등록 성공, 새 상태 업로드, 세션 한도, 워치타워 가용성을 지켜봐야 합니다. 폐기 전 영구 저장, 재연결 검증, 온체인 감시가 하나로 이어진 안전 흐름입니다.
자주 묻는 질문
왜 commitment transaction이 한 장이 아닌가요?
참여자마다 상대의 협조 없이 채널을 닫을 수 있어야 하므로, 같은 상태를 반영한 각자의 커밋먼트 거래를 보관합니다.
revoke_and_ack를 보내면 현재 상태도 폐기되나요?
아닙니다. 새 커밋먼트 거래를 안전하게 확보한 뒤 이전 커밋먼트의 비밀값을 공개해 그 이전 상태만 폐기합니다.
최신 commitment를 방송해도 벌금을 내나요?
최신 유효 상태로 일방 폐쇄하는 것은 정상 경로이며 폐기 벌칙 대상이 아닙니다. 다만 CSV 지연과 HTLC 정산 비용은 발생합니다.
Seed만 있으면 채널을 완전히 복구할 수 있나요?
일반적으로 시드만으로는 최신 오프체인 상태 전체를 다시 만들 수 없습니다. 사용하는 구현의 채널 데이터베이스와 백업·복구 절차가 필요합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
