IBC 패킷의 timeout과 acknowledgement 읽기

IBC 송신 체인의 거래가 성공해도 목적지 앱 처리가 끝난 것은 아니다. 패킷 commitment 생성, relayer 전달, 목적지 수신, acknowledgement 작성과 역방향 전달이 이어져야 송신 측 상태가 마무리된다. 정해진 높이 또는 시각을 넘겼다면 acknowledgement를 기다리는 대신 timeout 증명과 애플리케이션의 환불 처리를 확인한다.

IBC 전송을 한 번의 거래로 보면 생기는 오해

IBC 패킷은 source port, source channel, destination port, destination channel, sequence, data, timeout height와 timeout timestamp를 담는다. 송신 체인에서 SendPacket이 처리되면 패킷 commitment가 저장되지만, 목적지 체인의 수신 거래는 relayer가 별도로 제출한다. 그래서 첫 거래의 success 표시만으로 목적지 잔액을 확정할 수 없다.

릴레이어는 합의 주체가 아니라 두 체인의 증거와 메시지를 전달하는 역할이다. 특정 릴레이어가 멈춰도 다른 릴레이어가 유효한 증거를 제출할 수 있다. 다만 채널이 닫혔거나 목적지 앱이 오류 acknowledgement를 썼다면 단순 재전송으로 해결되지 않는다.

IBC 전송 상태는 송신, 수신, 응답, 정산의 네 증거로 나누어 읽는다.

JOBCOIN 해설

acknowledgement가 말해 주는 것

목적지 애플리케이션은 패킷을 처리한 뒤 acknowledgement를 기록할 수 있다. 일반적인 동기 모델에서는 수신과 함께 결과 또는 오류 응답을 쓰며, 비동기 앱은 나중에 응답을 기록할 수도 있다. IBC 코어는 acknowledgement 바이트의 사업 의미를 대신 결정하지 않으므로 사용한 앱의 인코딩 규칙을 확인해야 한다.

acknowledgement가 송신 체인으로 돌아오면 원래 애플리케이션이 결과에 따라 상태를 정리한다. 토큰 전송 앱에서는 성공 응답과 오류 응답의 처리 방식이 다르다. 탐색기에 acknowledgement 이벤트가 있다는 사실만 보지 말고 result와 error 중 어느 분기인지 확인한다.

timeout height와 timestamp 비교

timeout height는 대상 체인의 합의 높이를 기준으로 하고 timeout timestamp는 대상 체인의 합의 시각을 기준으로 한다. 둘 중 설정된 조건이 충족되면 송신 측에서 timeout 절차를 시도할 수 있다. 로컬 시계가 표시한 시간이 지났다는 사실만으로 패킷이 자동 환불되지는 않는다.

탐색기에서 멈춘 위치 찾기

먼저 송신 거래에서 channel과 sequence를 기록한다. 목적지 체인의 해당 채널에서 같은 sequence의 RecvPacket을 찾고, 이어 WriteAcknowledgement가 있는지 본다. 마지막으로 송신 체인에서 AcknowledgePacket 또는 TimeoutPacket을 확인한다. 체인마다 탐색기 명칭이 달라도 이 식별자 조합은 유지된다.

가정 예시로 sequence 42의 송신은 성공했지만 목적지 수신이 없고 timeout timestamp가 지났다면, relayer가 미수신 증명을 포함한 timeout 메시지를 제출해야 한다. 반대로 목적지에 이미 수신됐다면 같은 패킷의 timeout은 허용되지 않아야 한다. 이는 교육용 흐름이며 실제 환불 결과는 앱 구현과 채널 상태에 달려 있다.

• 송신 tx에서 source channel과 sequence를 복사한다
• 목적지 체인의 RecvPacket 존재 여부를 확인한다
• acknowledgement가 result인지 error인지 디코딩한다
• 송신 체인의 AcknowledgePacket 또는 TimeoutPacket을 찾는다
• 지원팀 문의에는 두 체인 tx와 channel·sequence를 함께 제공한다

재시도 전에 확인할 위험

수신이 늦다고 같은 자산을 다시 보내면 독립된 새 sequence가 만들어져 두 전송이 모두 처리될 수 있다. 기존 패킷의 상태를 먼저 추적하고, 지갑이 제공하는 retry 버튼이 릴레이 재요청인지 새 송신인지 구분한다. 새 tx 해시가 생성되는 동작이라면 금액과 수수료를 다시 검토한다.

채널의 counterparty 정보가 맞지 않거나 앱 버전 협상이 다른 경로로 송신하면 표시 자산의 denom trace도 달라질 수 있다. 기호가 같아도 경로가 다르면 별도 바우처이므로 최종 denom과 채널을 함께 본다.

운영자와 이용자가 남길 기록

이용자는 송신·수신 체인, 양쪽 채널, sequence, timeout 조건, 두 체인의 tx 해시를 남긴다. 운영자는 relayer 큐, 클라이언트 만료 여부, 채널 상태, 가스 부족과 acknowledgement 오류를 분리해 보고한다. 'IBC 장애'라는 한 문장으로는 영향 범위를 판단할 수 없다.

timeout과 acknowledgement는 전달 실패를 안전하게 정산하기 위한 상태 기계의 일부다. 특정 브리지나 토큰의 경제적 안전성, 가격, 발행자 상환 능력을 보증하지 않는다. 실시간 체인 상태를 보지 않은 설명은 개별 전송 완료 주장으로 사용하지 않는다.

자주 묻는 질문