워치타워 클라이언트는 채널 상태가 폐기될 때마다 해당 상태를 찾을 수 있는 locator와, breach transaction이 나타났을 때만 열 수 있도록 만든 암호화된 justice kit를 타워에 보냅니다. 타워는 새 블록의 거래를 locator와 대조하고 일치하면 commitment transaction ID에서 키를 유도해 kit 복호화를 시도한 뒤 미리 서명된 penalty transaction을 완성·방송합니다. 타워는 사용자의 seed나 현재 채널 잔액을 복구하는 백업이 아니며, 상태별 업로드 성공과 체인 감시·수수료 정책을 별도로 관리해야 합니다.
워치타워는 폐기 상태의 대신 방송하는 역할입니다
라이트닝 노드는 상대가 폐기된 commitment를 방송하면 to_self_delay가 끝나기 전에 revocation 경로로 대응해야 합니다. 노트북이나 모바일 지갑처럼 항상 online이 아닌 클라이언트는 이 감시 창을 놓칠 수 있습니다. Watchtower는 새 블록을 지속해서 살피고 미리 위탁받은 breach remedy를 대신 방송하는 역할입니다.
타워가 채널을 운영하거나 새 payment에 서명하는 것은 아닙니다. 또한 현재 commitment를 대신 보관해 채널을 정상 복구시키는 일반 backup service도 아닙니다. 역할은 이미 폐기된 특정 상태가 체인에 나타났을 때 그 위반을 처벌하는 범위로 좁혀야 합니다.
워치타워는 금고 열쇠를 보관하는 곳이 아니라, 폐기된 영수증이 제출됐을 때만 작동하는 봉인된 대응 거래를 맡는 감시소입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 워치타워는 폐기 상태의 대신 방송하는 역할입니다
라이트닝 노드는 상대가 폐기된 commitment 를 방송하면 to_self_delay 가 끝나기 전에 revocation 경로로 대응해야 합니다.
- Locator와 암호화 blob이 정보 노출을 줄입니다
LND watchtower 구현의 JusticeKit은 sweep address, to-local·HTLC revocation signatures 등 breach 대응에 필요한 자료를 담습니다.
- 상태 N 폐기부터 justice 방송까지 이어집니다
Alice와 Bob이 상태 N+1로 전진해 Bob의 상태 N을 폐기했다고 가정하겠습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Locator와 암호화 blob이 정보 노출을 줄입니다
LND watchtower 구현의 JusticeKit은 sweep address, to-local·HTLC revocation signatures 등 breach 대응에 필요한 자료를 담습니다. 클라이언트는 상태별 breach transaction ID에서 파생한 키로 kit를 암호화하고 짧은 locator와 함께 등록합니다. 타워는 locator 후보가 맞을 때 transaction ID 기반 키로 복호화를 시도합니다.
이 구조는 평상시에 타워가 kit 내용을 바로 읽고 채널을 식별하는 범위를 줄입니다. 그러나 타워는 클라이언트 연결 시점, update 수와 locator 후보 같은 metadata를 볼 수 있고 breach 발생 뒤에는 대응 출력도 관찰합니다. 암호화되었다는 이유로 완전한 익명 서비스라고 표현해서는 안 됩니다.
| 주체 | 보유·관찰 자료 | 할 수 없는 일 |
|---|---|---|
| 클라이언트 | 채널 상태·revocation 자료 | offline 중 체인 직접 감시 |
| 타워 | locator·암호화 blob·chain transactions | 새 결제 승인·seed 복구 |
| 위반 상대 | 폐기 commitment transaction | to_self_delay 뒤 안전 보장 |
| 체인 관찰자 | breach·justice transactions | 암호화 kit 원문 열람 |
| 지갑 백업 | 구현별 복구 자료 | 폐기 상태 자동 처벌 |
상태 N 폐기부터 justice 방송까지 이어집니다
Alice와 Bob이 상태 N+1로 전진해 Bob의 상태 N을 폐기했다고 가정하겠습니다. Alice의 client는 Bob의 폐기 commitment에 대응할 signatures와 sweep script를 kit에 넣어 tower session에 upload합니다. Bob이 나중에 상태 N 거래를 방송하면 타워는 블록 또는 mempool 관찰에서 locator가 맞는 후보를 찾습니다.
복호화와 signature 검증이 성공하면 타워는 kit의 자료로 justice transaction을 구성해 위반 출력들을 지정된 sweep address로 보냅니다. BOLT 5가 설명하는 on-chain 처리처럼 confirmation과 재조직, competing spends와 fee 조건을 추적해야 합니다. 단 한 번 broadcast RPC 성공 응답만으로 보호 완료라고 판단할 수 없습니다.
- 신뢰할 tower public key와 service policy를 등록합니다.
- 폐기 상태마다 session sequence와 update 응답을 영구 기록합니다.
- 업로드 실패를 재시도하되 세션 한도 초과를 별도 경보로 냅니다.
- 타워가 mempool과 새 블록을 계속 동기화하는지 확인합니다.
- Justice transaction의 confirmation과 reorg 이후 상태까지 추적합니다.
가용성과 수수료 정책이 실제 보호 범위를 정합니다
타워가 to_self_delay 전체 동안 offline이거나 chain backend가 뒤처지면 대응 기회를 잃을 수 있습니다. 여러 독립 타워에 같은 상태를 위탁하면 단일 장애점을 줄일 수 있지만, update 성공 여부와 각 타워의 retention·session quota를 실제로 점검해야 합니다.
Penalty transaction이 mempool 최소 수수료를 충족하지 못하면 broadcast가 지연될 수 있습니다. 구현은 보상 출력, 타워 수수료 또는 anchor·CPFP 같은 실제 지원 전략을 기준으로 fee policy를 정합니다. BOLT 형식과 구현별 watchtower protocol은 같지 않으므로 LND의 JusticeKit 필드를 모든 타워 표준으로 일반화하지 않습니다.
백업과 감시를 한 곳 이상에 성공적으로 등록했는지
첫째, node seed와 static channel backup 등 구현이 요구하는 복구 자료를 검증합니다. 둘째, active channel database가 상태 전환과 함께 durable하게 저장되는지 확인합니다. 셋째, watchtower client가 새 폐기 상태를 최소 한 곳 이상에 성공적으로 등록했는지 monitoring합니다.
복구 시험에서는 채널 database를 임의로 과거 상태로 되돌려 실제 peer에 연결하면 안 됩니다. 폐기 상태 방송 위험이 생길 수 있기 때문입니다. 격리된 fixture·regtest에서 tower registration, breach 탐지와 sweep confirmation까지 연습하고 운영 데이터에는 읽기 전용 무결성 검사를 적용합니다.
자주 묻는 질문
워치타워에 seed를 맡겨야 하나요?
아닙니다. 일반적인 watchtower 설계는 breach 대응에 필요한 제한된 암호화 자료를 맡기며 지갑 seed를 요구하지 않습니다.
타워 하나만 등록하면 안전한가요?
타워의 offline·동기화·보존 실패가 가능하므로 복수 독립 타워와 자체 감시를 결합하고 update 성공을 확인하는 편이 안전합니다.
워치타워가 최신 채널 상태를 복구해 주나요?
그 역할이 아닙니다. 최신 상태 복구에는 사용 구현의 channel database와 backup 절차가 따로 필요합니다.
Justice transaction을 방송하면 즉시 끝나나요?
아닙니다. 수수료 경쟁, confirmation과 reorg를 추적해 위반 출력이 최종적으로 회수됐는지 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
