워치타워(watchtower) 클라이언트는 채널 상태가 폐기될 때마다 두 가지를 타워에 보냅니다. 해당 상태를 찾아낼 수 있는 위치 표지(locator)와, 위반 거래가 나타났을 때만 열리도록 만든 암호화된 처벌 꾸러미(justice kit)입니다. 타워는 새 블록의 거래를 위치 표지와 맞춰 보고, 일치하면 약정 거래(commitment transaction) ID에서 키를 끌어내 꾸러미를 풀어 본 뒤 미리 서명된 처벌 거래를 완성해 방송합니다. 타워는 사용자의 시드나 현재 채널 잔액을 되살려 주는 백업이 아닙니다. 상태별 업로드 성공 여부와 체인 감시, 수수료 정책은 따로 관리해야 합니다.
워치타워는 폐기 상태가 나타나면 대신 방송합니다
라이트닝 노드는 상대가 폐기된 약정 거래를 방송하면 to_self_delay가 끝나기 전에 폐기 경로로 대응해야 합니다. 노트북이나 모바일 지갑처럼 늘 접속해 있지 않은 클라이언트는 이 감시 시간을 놓칠 수 있습니다. 워치타워는 새 블록을 꾸준히 살피다가 미리 맡겨 둔 위반 대응 거래를 대신 방송하는 역할입니다.
타워가 채널을 운영하거나 새 결제에 서명하지는 않습니다. 현재 약정 거래를 대신 보관해 채널을 정상 복구해 주는 일반 백업 서비스도 아닙니다. 역할은 이미 폐기된 특정 상태가 체인에 나타났을 때 그 위반을 처벌하는 일로 좁혀서 이해해야 합니다.
워치타워는 금고 열쇠를 맡아 두는 곳이 아닙니다. 폐기된 영수증이 제출됐을 때만 작동하는 봉인된 대응 거래를 맡아 둔 감시소입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 워치타워는 폐기 상태가 나타나면 대신 방송합니다
라이트닝 노드는 상대가 폐기된 약정 거래를 방송하면 to_self_delay가 끝나기 전에 폐기 경로로 대응해야 합니다.
- 위치 표지와 암호화 덩어리가 정보 노출을 줄입니다
LND 워치타워 구현의 JusticeKit에는 회수 주소, 자기 쪽 출력과 HTLC의 폐기 서명처럼 위반 대응에 필요한 자료가 담깁니다.
- 상태 N 폐기부터 처벌 거래 방송까지 이어집니다
앨리스와 밥이 상태 N+1로 넘어가면서 밥의 상태 N을 폐기했다고 해 보겠습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
위치 표지와 암호화 덩어리가 정보 노출을 줄입니다
LND 워치타워 구현의 JusticeKit에는 회수 주소, 자기 쪽 출력과 HTLC의 폐기 서명처럼 위반 대응에 필요한 자료가 담깁니다. 클라이언트는 상태별 위반 거래 ID에서 뽑아낸 키로 꾸러미를 암호화하고, 짧은 위치 표지와 함께 등록합니다. 타워는 위치 표지 후보가 맞을 때 거래 ID로 만든 키로 복호화를 시도합니다.
이 구조 덕분에 평소에는 타워가 꾸러미 내용을 바로 읽거나 채널을 알아보기 어렵습니다. 그래도 타워는 클라이언트 접속 시점, 갱신 횟수, 위치 표지 후보 같은 부가 정보를 볼 수 있고, 위반이 일어난 뒤에는 대응 출력도 지켜봅니다. 암호화됐다는 이유만으로 완전한 익명 서비스라고 표현해서는 안 됩니다.
| 주체 | 보유·관찰 자료 | 할 수 없는 일 |
|---|---|---|
| 클라이언트 | 채널 상태·폐기 자료 | 접속이 끊긴 동안 체인 직접 감시 |
| 타워 | 위치 표지·암호화 덩어리·체인 거래 | 새 결제 승인·시드 복구 |
| 위반 상대 | 폐기된 약정 거래 | to_self_delay 이후의 안전 보장 |
| 체인 관찰자 | 위반 거래·처벌 거래 | 암호화 꾸러미 원문 열람 |
| 지갑 백업 | 구현별 복구 자료 | 폐기 상태 자동 처벌 |
상태 N 폐기부터 처벌 거래 방송까지 이어집니다
앨리스와 밥이 상태 N+1로 넘어가면서 밥의 상태 N을 폐기했다고 해 보겠습니다. 앨리스의 클라이언트는 밥의 폐기 약정 거래에 맞설 서명과 회수 스크립트를 꾸러미에 넣어 타워 세션에 올립니다. 나중에 밥이 상태 N 거래를 방송하면, 타워는 블록이나 멤풀을 살피다가 위치 표지가 맞는 후보를 찾아냅니다.
복호화와 서명 검증이 성공하면 타워는 꾸러미 자료로 처벌 거래를 꾸려 위반 출력들을 지정된 회수 주소로 보냅니다. BOLT 5가 설명하는 온체인 처리처럼 확인 수, 체인 재편성, 경쟁 지출, 수수료 조건을 계속 추적해야 합니다. 방송 RPC가 성공 응답을 한 번 돌려줬다고 보호가 끝났다고 판단할 수는 없습니다.
- 믿을 수 있는 타워 공개키와 서비스 정책을 등록합니다.
- 폐기 상태마다 세션 순번과 갱신 응답을 영구 기록합니다.
- 업로드가 실패하면 다시 시도하되, 세션 한도 초과는 별도 경보로 알립니다.
- 타워가 멤풀과 새 블록을 계속 따라잡고 있는지 확인합니다.
- 처벌 거래의 확인 수와 체인 재편성 이후 상태까지 추적합니다.
가용성과 수수료 정책이 실제 보호 범위를 정합니다
to_self_delay 기간 내내 타워가 꺼져 있거나 체인 연동 서버가 뒤처지면 대응할 기회를 잃을 수 있습니다. 서로 독립된 타워 여러 곳에 같은 상태를 맡기면 한 곳이 무너져 전체가 멈추는 위험을 줄일 수 있습니다. 다만 갱신이 실제로 성공했는지, 타워마다 보존 기간과 세션 한도가 어떤지는 직접 점검해야 합니다.
처벌 거래가 멤풀 최소 수수료를 채우지 못하면 방송이 늦어질 수 있습니다. 구현은 보상 출력, 타워 수수료, 앵커·CPFP처럼 실제로 지원하는 전략을 바탕으로 수수료 정책을 정합니다. BOLT 형식과 구현별 워치타워 프로토콜은 같지 않으므로 LND의 JusticeKit 필드를 모든 타워의 표준인 것처럼 일반화하지 않습니다.
백업과 감시를 따로 확인합니다
첫째, 노드 시드와 정적 채널 백업처럼 구현이 요구하는 복구 자료를 검증합니다. 둘째, 활성 채널 데이터베이스가 상태가 바뀔 때마다 확실히 디스크에 저장되는지 확인합니다. 셋째, 워치타워 클라이언트가 새 폐기 상태를 최소 한 곳 이상에 성공적으로 등록했는지 지켜봅니다.
복구를 시험할 때 채널 데이터베이스를 마음대로 과거 상태로 돌려 실제 피어에 연결해서는 안 됩니다. 폐기된 상태를 방송하게 될 위험이 있기 때문입니다. 격리된 시험 데이터나 회귀 테스트망(regtest)에서 타워 등록, 위반 탐지, 회수 거래 확인까지 연습하고, 운영 데이터에는 읽기 전용 무결성 검사만 적용하세요.
자주 묻는 질문
워치타워에 seed를 맡겨야 하나요?
아닙니다. 일반적인 워치타워 설계는 위반 대응에 필요한 제한된 암호화 자료만 맡기며 지갑 시드를 요구하지 않습니다.
타워 하나만 등록하면 안전한가요?
타워가 꺼지거나 동기화·보존에 실패할 수 있으니, 독립된 타워 여러 곳과 자체 감시를 함께 쓰고 갱신 성공을 확인하는 편이 안전합니다.
워치타워가 최신 채널 상태를 복구해 주나요?
그건 워치타워의 역할이 아닙니다. 최신 상태를 복구하려면 쓰는 구현의 채널 데이터베이스와 백업 절차가 따로 필요합니다.
Justice transaction을 방송하면 즉시 끝나나요?
아닙니다. 수수료 경쟁, 확인 수, 체인 재편성을 추적해 위반 출력이 최종적으로 회수됐는지 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
