IBC는 한 체인의 상태에 포함된 메시지를 다른 체인이 라이트 클라이언트와 머클 증명으로 검증해 처리하도록 하는 상호운용 프로토콜입니다. relayer는 패킷과 증명을 전달하지만 원칙적으로 메시지 내용을 신뢰해 승인하는 주체가 아니며, 안전성은 채택한 light client와 두 체인의 합의에 달려 있습니다.
IBC는 다리 운영자의 서명보다 상태 증명을 운반한다
체인 A의 애플리케이션이 패킷을 만들면 Core IBC가 약속된 상태 경로에 커밋먼트를 기록한다. relayer는 패킷, 해당 포함을 보이는 머클 증명, 필요한 상대 체인 헤더 업데이트를 체인 B로 전달한다. B의 IBC 모듈은 보유한 A light client 상태에 대해 증명을 검증한다.
IBC transport and application layers는 light client, connection, channel, relayer를 층별로 설명한다. relayer가 꺼지면 전달이 지연될 수 있지만 임의 메시지를 만들면 증명 검증을 통과해야 한다.
‘trust-minimized’는 신뢰가 0이라는 뜻이 아니다. 상대 체인 합의와 light client 검증 코드, 업그레이드·거버넌스, 애플리케이션 모듈의 정확성을 전제한다.
| 구성요소 | 역할 | 실패 영향 |
|---|---|---|
| Light client | 상대 체인 헤더·상태 검증 | 만료·오류 시 메시지 검증 중단 |
| Connection | 두 light client 관계 설정 | 연결 상태·버전 불일치 |
| Channel | 앱 포트·순서·패킷 경로 | 채널 종료·순서 오류 |
| Relayer | 패킷·증명·ack 전달 | 지연·가스 부족 |
| Application | 토큰 발행·콜백 처리 | 회계·권한 버그 |
| Source/Destination chain | 최종성·상태 제공 | 체인 중단·합의 공격 |
connection과 channel을 구분한다
connection은 두 체인의 light client 사이에 신뢰 가능한 통신 관계를 맺는 전송 계층 추상화다. 그 위에 여러 channel을 열 수 있고 각 channel은 특정 애플리케이션 포트끼리 패킷을 교환한다. 하나의 체인쌍이라도 토큰 전송과 다른 앱이 별도 채널을 쓸 수 있다.
채널 ID만 복사하면 안전하지 않다. source port/channel, destination port/channel, counterparty chain, ordering, version을 함께 확인한다. UI의 추천 경로가 오래되거나 닫힌 채널을 가리킬 수 있다.
패킷의 성공은 acknowledgement까지 봐야 한다
recvPacket이 목적지에서 성공하면 애플리케이션이 패킷을 처리하고 acknowledgement를 기록한다. relayer는 이 증명을 다시 원체인으로 전달해 송신 측이 성공 결과를 처리하게 한다. 목적지 거래가 포함됐다는 사실과 원체인의 ack 처리가 끝난 시점은 다를 수 있다.
IBC and CCIP analysis의 단계처럼 패킷 커밋, recv, receipt, 앱 콜백, acknowledgement가 이어진다. 탐색기에서 send_packet 이벤트 하나만 보고 완료로 단정하지 않는다.
timeout은 실패를 증명하는 별도 경로다
패킷에는 목적지 높이 또는 timestamp 기준 timeout을 둘 수 있다. 기한까지 목적지에서 수신되지 않았음을 상대 체인 상태 증명으로 보여 원체인에서 timeout 처리를 한다. 단순 로컬 시계나 relayer 오류 메시지만으로 환불되지 않는다.
목적지 체인이 멈추거나 light client가 만료되면 최신 상태 증명을 얻는 과정이 어려워질 수 있다. 복구에는 client update나 거버넌스 절차가 필요할 수 있다. 앱이 timeout 때 토큰을 올바르게 되돌리는지도 모듈 로직에 달려 있다.
- 원본 체인·목적 체인과 토큰 denom 확인
- port/channel과 counterparty 매핑 확인
- packet sequence·timeout height/time 기록
- recvPacket 뒤 acknowledgement 상태 확인
- light client 최신 높이·만료 여부 확인
ICS-20 토큰은 이동보다 잠금·표현에 가깝다
대표 토큰 전송에서 원본 자산은 source 쪽 에스크로에 잠기고 destination에는 voucher가 발행될 수 있다. 되돌아갈 때 voucher를 소각하고 원본을 해제한다. 경로가 여러 체인을 지나면 denom trace가 달라져 같은 표시 기호라도 다른 자산이 된다.
지갑의 ATOM 같은 ticker보다 전체 denom trace와 채널 경로를 확인한다. 잘못된 채널로 보낸 voucher가 유동성·앱 지원을 잃을 수 있다. 토큰 목록의 로고는 계약상 동일성을 보장하지 않는다.
IBC에서 relayer는 우편배달부이고, 편지가 진짜인지 판정하는 것은 목적지 체인의 light client다.
JOBCOIN 해설
IBC 전송 한 건을 끝까지 추적한다
원체인 거래의 send_packet 이벤트에서 sequence, source channel, destination channel, timeout, packet data를 읽는다. 목적지 탐색기에서 같은 sequence의 recv_packet과 애플리케이션 처리 결과를 찾고, 다시 원체인의 acknowledge_packet을 확인한다.
relayer 대시보드는 검색 편의를 주지만 프로토콜 증거를 대신하지 않는다. 양 체인의 높이와 거래 해시, light client 업데이트를 기록한다. timeout이면 목적지 미수신 증명과 원체인 환불 이벤트를 확인한다.
체인 재시작·업그레이드 후 client 상태가 복구돼도 이미 timeout된 패킷을 임의로 성공 처리할 수 있는 것은 아니다. 앱별 재전송·환불 절차를 공식 문서에서 확인하고 같은 sequence를 중복 제출하지 않는다.
자주 묻는 질문
relayer가 토큰을 훔칠 수 있나요?
정상 IBC는 목적지 체인이 light client와 증명을 검증하므로 relayer의 임의 메시지는 통과하지 않습니다. 앱·client 버그와 체인 합의 위험은 남습니다.
send_packet이 성공하면 전송이 끝난 건가요?
아닙니다. 목적지 recv 처리와 원체인 acknowledgement까지 확인해야 전체 수명주기를 알 수 있습니다.
같은 ATOM 표시라면 같은 자산인가요?
여러 채널·경로의 voucher가 같은 ticker를 쓸 수 있습니다. 전체 IBC denom trace와 원본 체인을 확인하세요.
