IBC 패킷 데이터가 소스 체인에 남아 있어도, 목적 체인의 라이트 클라이언트가 신뢰 기간(trusting period)을 넘겨 버리면 새 증명을 안전하게 검증할 기준이 끊길 수 있습니다. 릴레이어는 패킷만 나르는 것이 아니라 상대 체인의 최신 합의 헤더를 주기적으로 갱신해야 합니다. 만료 여부는 마지막 합의 상태의 타임스탬프, 클라이언트의 신뢰 기간, 현재 시각을 같은 기준으로 맞춰 비교해 판단합니다.
패킷과 검증 기준은 별개의 상태입니다
IBC 패킷 커밋먼트는 소스 체인에 기록되지만, 목적 체인은 그 체인을 처음부터 끝까지 직접 실행하지 않습니다. 대신 로컬 IBC 라이트 클라이언트가 상대 체인의 합의 상태와 검증자 정보를 추적하고, 릴레이어가 가져온 머클 증명을 검증합니다. 패킷 바이트가 존재한다는 사실만으로 목적 체인이 증명을 신뢰할 수 있는 것은 아닙니다.
Tendermint 계열 클라이언트는 신뢰하던 합의 상태에서 최신 헤더로 넘어갈 때 신뢰 기간과 검증자 중첩 같은 안전 조건을 확인합니다. 마지막 신뢰 상태가 너무 오래되면 그동안 쌓인 검증자 세트 변화를 안전하게 건너뛸 기준이 사라집니다. 그래서 패킷 중계가 뜸한 채널도 클라이언트 갱신은 꼭 필요합니다.
IBC에서 패킷은 전달할 화물이고, 라이트 클라이언트 갱신은 그 화물의 봉인을 검증할 유효한 검사표입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 패킷과 검증 기준은 별개의 상태입니다
IBC 패킷 커밋먼트는 소스 체인에 기록되지만, 목적 체인은 그 체인을 처음부터 끝까지 직접 실행하지 않습니다.
- 신뢰 기간은 패킷 시간 초과와 다릅니다
신뢰 기간은 클라이언트가 기존 신뢰 상태를 바탕으로 새 헤더를 검증할 수 있는 시간 조건입니다.
- 만료 진단은 클라이언트 상태에서 시작합니다
먼저 클라이언트 식별자, 클라이언트 상태, 최신 높이, 신뢰 기간을 조회합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
신뢰 기간은 패킷 시간 초과와 다릅니다
신뢰 기간은 클라이언트가 기존 신뢰 상태를 바탕으로 새 헤더를 검증할 수 있는 시간 조건입니다. 패킷 시간 초과 높이나 타임스탬프는 특정 패킷이 목적 체인에서 처리되지 않았을 때, 소스 체인에서 시간 초과 증명을 쓸 수 있게 되는 조건입니다. 하나는 검증 인프라의 유효성이고 다른 하나는 패킷의 수명입니다.
클라이언트가 만료되지 않았어도 패킷 시간 초과는 지날 수 있고, 패킷 기한이 넉넉해도 클라이언트가 먼저 만료될 수 있습니다. 연결 지연 기간(delay period) 역시 증명이 만들어진 뒤 일정 시간을 기다리게 하는 별도의 안전 조건입니다. 대시보드는 이 세 값을 ‘만료’라는 한 열로 뭉뚱그리지 않아야 합니다.
| 조건 | 대상 | 초과 시 주된 영향 |
|---|---|---|
| 신뢰 기간 | 라이트 클라이언트 합의 상태 | 새 헤더·증명 검증이 멈출 수 있음 |
| 패킷 시간 초과 높이 | 개별 패킷 | 소스 체인 시간 초과 경로 열림 |
| 패킷 시간 초과 타임스탬프 | 개별 패킷 | 시간 기준 시간 초과 경로 열림 |
| 지연 기간 | 연결 증명 | 증명 사용 전 대기 |
만료 진단은 클라이언트 상태에서 시작합니다
먼저 클라이언트 식별자, 클라이언트 상태, 최신 높이, 신뢰 기간을 조회합니다. 그다음 저장된 최신 합의 상태의 타임스탬프와 현재 체인 시각을 비교합니다. 로컬 컴퓨터 시계나 릴레이어 로그 시각만 쓰면 체인 타임스탬프와 어긋날 수 있습니다. 동결(frozen) 클라이언트는 부정행위 증거 때문에 멈춘 상태이므로 만료와 구분합니다.
릴레이어 대기열에 패킷이 쌓였다고 해서 곧바로 만료로 단정하지 않습니다. 잔액 부족, RPC 장애, 연결 지연, 잘못된 경로 설정, 수수료 정책도 똑같은 지연을 만들 수 있습니다. 클라이언트 갱신 거래의 최근 성공·실패와 오류 코드, 양쪽 체인이 정상적으로 진행 중인지를 함께 봅니다.
- 양쪽 체인의 클라이언트 식별자와 최신 높이·상태를 기록합니다
- 최신 합의 상태 타임스탬프와 신뢰 기간을 체인 시각 기준으로 계산합니다
- 최근 MsgUpdateClient 결과와 릴레이어 오류를 확인합니다
- 패킷 시간 초과·연결 지연·잔액 문제는 별도 열에서 배제합니다
만료 뒤 복구는 새 헤더 한 건으로 끝나지 않을 수 있습니다
신뢰 기간이 이미 지난 클라이언트는 단순 갱신이 거부될 수 있습니다. 거버넌스를 통한 클라이언트 복구나 새 클라이언트·연결·채널 생성 같은 복구 방식은 체인과 IBC 버전, 활성 모듈에 따라 다릅니다. 운영자가 임의로 시간을 되돌리거나 신뢰 높이를 바꾸는 식의 해결책은 안전 가정을 깨뜨립니다.
복구에 앞서 처리되지 않은 패킷 커밋먼트, 수신 확인, 시간 초과 가능성을 목록으로 정리합니다. 새 채널을 만들었다고 기존 패킷이 자동으로 옮겨 가지는 않습니다. 자산 전송 앱이라면 토큰 표기 추적 정보와 예치 상태까지 확인해야 사용자 잔액을 잘못 보여 주지 않습니다.
운영 목표는 패킷이 없을 때도 갱신하는 것입니다
릴레이어는 트래픽이 있을 때만 클라이언트를 갱신할 수도, 주기적으로 유지할 수도 있습니다. 활동이 적은 채널이라면 갱신 비용과 만료 위험을 견줘 보고, 신뢰 기간보다 충분히 짧은 경보·실행 간격을 둡니다. 릴레이어 하나에만 기대고 있다면 장애나 잔액 고갈이 곧 만료로 이어질 수 있습니다.
모니터링은 남은 신뢰 시간, 최신 높이 지연, 마지막 갱신 거래 이후 경과 시간, 릴레이어 잔액을 함께 알려야 합니다. ‘패킷이 안 간다’는 사용자 증상이 나온 뒤에 들여다보는 것보다 만료 전에 경보를 받는 편이 싸고 안전합니다. 다만 권한 없음, 동결, 잘못된 헤더 같은 오류에서는 자동 재시도를 멈추고 원인부터 확인해야 합니다.
자주 묻는 질문
패킷이 소스 체인에 있으면 클라이언트가 만료돼도 보낼 수 있나요?
패킷이 있다는 것만으로는 부족합니다. 목적 체인의 클라이언트가 해당 증명을 검증할 수 있어야 처리됩니다.
신뢰 기간과 패킷 시간 초과는 같은 값인가요?
아닙니다. 앞의 것은 라이트 클라이언트의 신뢰 상태, 뒤의 것은 개별 패킷의 처리 기한입니다.
만료된 클라이언트는 릴레이어를 재시작하면 복구되나요?
단순 재시작으로는 해결되지 않을 수 있습니다. 체인별 복구 절차나 새 연결 경로를 검토해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
