IBC란? 체인 사이 메시지를 검증하는 방식

IBC는 한 체인의 상태에 담긴 메시지를 다른 체인이 라이트 클라이언트와 머클 증명으로 검증한 뒤 처리하게 하는 상호운용 프로토콜입니다. 중계자(relayer)는 패킷과 증명을 실어 나를 뿐, 원칙적으로 메시지 내용을 믿고 승인하는 쪽이 아닙니다. 안전성은 어떤 라이트 클라이언트를 쓰는지와 두 체인의 합의가 얼마나 튼튼한지에 달려 있습니다.

IBC는 다리 운영자의 서명 대신 상태 증명을 나릅니다

체인 A의 애플리케이션이 패킷을 만들면 Core IBC가 정해진 상태 경로에 커밋먼트를 남깁니다. 중계자는 패킷과 그 포함 사실을 보여 주는 머클 증명, 필요한 상대 체인 헤더 업데이트를 체인 B로 넘깁니다. B의 IBC 모듈은 자신이 들고 있는 A의 라이트 클라이언트 상태에 비춰 증명을 검증합니다.

IBC transport and application layers 글은 라이트 클라이언트, 연결, 채널, 중계자를 층별로 풀어 설명합니다. 중계자가 멈추면 전달이 늦어질 수는 있습니다. 그래도 멋대로 만든 메시지는 증명 검증을 넘어야만 받아들여집니다.

‘신뢰 최소화’는 신뢰가 0이라는 뜻이 아닙니다. 상대 체인의 합의, 라이트 클라이언트 검증 코드, 업그레이드와 거버넌스, 애플리케이션 모듈이 제대로 돌아간다는 전제가 깔려 있습니다.

그림으로 보기체인 사이의 검증 과정

1. 01
   IBC는 다리 운영자의 서명 대신 상태 증명을 나릅니다

   체인 A의 애플리케이션이 패킷을 만들면 Core IBC가 정해진 상태 경로에 커밋먼트를 남깁니다.

2. 02
   연결과 채널은 서로 다른 층입니다

   연결(connection)은 두 체인의 라이트 클라이언트 사이에 믿을 수 있는 통신 관계를 세우는 전송 계층 개념입니다.

3. 03
   패킷이 성공했는지는 확인 응답까지 봐야 압니다

   도착 체인에서 recvPacket이 성공하면 애플리케이션이 패킷을 처리하고 확인 응답(acknowledgement)을 기록합니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

연결과 채널은 서로 다른 층입니다

연결(connection)은 두 체인의 라이트 클라이언트 사이에 믿을 수 있는 통신 관계를 세우는 전송 계층 개념입니다. 그 위에 여러 채널(channel)을 열 수 있고, 채널마다 특정 애플리케이션 포트끼리 패킷을 주고받습니다. 같은 두 체인 사이라도 토큰 전송과 다른 앱이 각자 다른 채널을 쓸 수 있습니다.

채널 ID만 베껴 쓰는 것은 안전하지 않습니다. 출발 포트·채널, 도착 포트·채널, 상대 체인, 순서 방식, 버전을 함께 봐야 합니다. 화면에서 추천하는 경로가 낡았거나 이미 닫힌 채널일 수도 있습니다.

패킷이 성공했는지는 확인 응답까지 봐야 압니다

도착 체인에서 recvPacket이 성공하면 애플리케이션이 패킷을 처리하고 확인 응답(acknowledgement)을 기록합니다. 중계자는 이 증명을 다시 출발 체인으로 가져가 송신 쪽이 결과를 반영하게 합니다. 도착 체인에 거래가 담긴 시점과 출발 체인이 확인 응답 처리를 마친 시점은 다를 수 있습니다.

IBC and CCIP analysis에 정리된 단계처럼 패킷 커밋, 수신, 영수증, 앱 콜백, 확인 응답이 차례로 이어집니다. 탐색기에서 send_packet 이벤트 하나만 보고 끝났다고 판단하면 곤란합니다.

시간 초과는 실패를 증명하는 별도 경로입니다

패킷에는 도착 체인 높이나 타임스탬프를 기준으로 시간 초과(timeout)를 걸 수 있습니다. 기한 안에 도착 체인이 받지 않았다는 사실을 상대 체인 상태 증명으로 보여 줘야 출발 체인이 시간 초과 처리를 합니다. 내 컴퓨터 시계나 중계자 오류 메시지만으로는 환불되지 않습니다.

도착 체인이 멈추거나 라이트 클라이언트가 만료되면 최신 상태 증명을 구하기가 까다로워집니다. 되살리려면 클라이언트 업데이트나 거버넌스 절차를 거쳐야 할 수도 있습니다. 시간 초과 때 토큰을 제대로 돌려주는지도 결국 모듈 로직에 달린 문제입니다.

• 출발 체인·도착 체인과 토큰 denom을 확인합니다
• 포트·채널과 상대 체인 짝을 확인합니다
• 패킷 순번과 시간 초과 높이·시각을 적어 둡니다
• recvPacket 다음 확인 응답 상태를 봅니다
• 라이트 클라이언트 최신 높이와 만료 여부를 살핍니다

ICS-20 토큰은 옮겨 가기보다 잠그고 대신 표시하는 방식입니다

대표적인 토큰 전송에서는 원본 자산이 출발 쪽 에스크로에 잠기고, 도착 쪽에는 바우처(voucher)가 발행될 수 있습니다. 돌아올 때는 바우처를 태우고 원본을 풀어 줍니다. 여러 체인을 거쳐 온 토큰은 경로 기록(denom trace)이 달라져, 겉으로 같은 기호라도 서로 다른 자산이 됩니다.

지갑에 보이는 ATOM 같은 종목 기호보다 전체 경로 기록과 채널 경로를 확인하세요. 엉뚱한 채널로 보낸 바우처는 유동성도 앱 지원도 잃을 수 있습니다. 토큰 목록의 로고가 계약상 같은 자산임을 보장하지는 않습니다.

IBC에서 중계자는 우편배달부입니다. 편지가 진짜인지 가려내는 것은 도착 체인의 라이트 클라이언트입니다.

JOBCOIN 해설

IBC 전송 한 건을 끝까지 따라가 봅니다

출발 체인 거래의 send_packet 이벤트에서 순번, 출발 채널, 도착 채널, 시간 초과, 패킷 데이터를 읽습니다. 도착 체인 탐색기에서 같은 순번의 recv_packet과 애플리케이션 처리 결과를 찾고, 다시 출발 체인의 acknowledge_packet을 확인합니다.

중계자 대시보드는 찾기 편할 뿐 프로토콜 증거를 대신하지 못합니다. 두 체인의 높이와 거래 해시, 라이트 클라이언트 업데이트를 적어 두세요. 시간 초과가 났다면 도착 체인 미수신 증명과 출발 체인 환불 이벤트를 확인합니다.

체인이 재시작하거나 업그레이드된 뒤 클라이언트 상태가 돌아왔다고 해서, 이미 시간 초과된 패킷을 마음대로 성공 처리할 수는 없습니다. 앱마다 다른 재전송·환불 절차는 공식 문서에서 확인하고, 같은 순번을 두 번 제출하지 마세요.

자주 묻는 질문