IBC ordered와 unordered 채널: 패킷 순서가 실패 조건을 바꾸는 방식

ORDERED 채널에서는 목적 체인이 nextSequenceRecv와 정확히 일치하는 패킷만 차례대로 받습니다. 그래서 앞 패킷이 빠지면 뒤 패킷도 처리되지 않습니다. UNORDERED 채널은 순번마다 수신 기록(receipt)이 있는지로 중복을 막기 때문에, 서로 다른 패킷이 각자 따로 도착해도 됩니다. 순서 채널에서 패킷 시간 초과(timeout)가 성립하면 채널이 닫힌다는 규칙이 있어, 뒤따르는 패킷을 다시 보내는 전략도 달라집니다.

순서 방식은 채널 핸드셰이크에서 정해집니다

IBC의 기본 채널은 열릴 때 ORDERED와 UNORDERED 가운데 하나로 순서 방식을 합의합니다. 릴레이어(relayer)가 패킷을 어떤 순서로 발견했느냐에 따라 나중에 바꾸는 옵션이 아닙니다. 양쪽 채널 끝의 상대방 정보, 순서 방식, 버전이 핸드셰이크 증명으로 이어집니다. 앱은 자신이 원하는 의미에 맞는 순서 방식을 고릅니다.

순번(sequence)은 출발 포트와 채널에서 패킷을 보낼 때마다 하나씩 올라갑니다. 패킷에는 출발지·목적지, 순번, 시간 초과 조건, 데이터가 담깁니다. 같은 숫자라고 모든 채널을 통틀어 하나의 전역 순서를 뜻하지는 않습니다. 채널 경로마다 따로 매긴 순번을 섞어 보면 중복이나 빈 번호를 잘못 진단하게 됩니다.

IBC의 순서 방식은 택배 기사가 도착한 순서가 아닙니다. 목적 체인이 받아들일 수 있는 증명의 규칙입니다.

JOBCOIN 해설

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

1. 01
   순서 방식은 채널 핸드셰이크에서 정해집니다

   IBC의 기본 채널은 열릴 때 ORDERED와 UNORDERED 가운데 하나로 순서 방식을 합의합니다.

2. 02
   순서 채널에서는 빈 번호가 뒤를 막습니다

   ORDERED 채널의 RecvPacket은 패킷 순번이 nextSequenceRecv와 같은지 확인합니다.

3. 03
   확인 응답과 시간 초과는 서로 반대 방향의 증명을 씁니다

   목적 체인이 패킷을 처리하면 확인 응답(acknowledgement) 약정값을 기록하고, 릴레이어가 이를 출발 체인으로 가져옵니다.

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

순서 채널에서는 빈 번호가 뒤를 막습니다

ORDERED 채널의 RecvPacket은 패킷 순번이 nextSequenceRecv와 같은지 확인합니다. 10번을 기다리는 동안 11번의 증명이 먼저 와도 11번은 처리할 수 없습니다. 10번이 성공해야 다음 번호가 올라가고 11번을 받을 수 있습니다. 상태 변화가 순서에 기대는 앱에는 쓸모 있는 성질이지만, 앞 패킷의 장애가 뒤 패킷을 줄줄이 막는 선두 차단(head-of-line blocking)을 낳습니다.

UNORDERED 채널은 패킷 순번별 수신 기록이 아직 없는지 확인하고, 처리에 성공하면 기록을 남깁니다. 11번을 먼저 받고 10번을 나중에 받아도 되지만, 같은 11번을 두 번 처리하지는 않습니다. 앱 내부의 업무 순서까지 알아서 지켜 주지는 않으므로 데이터에 별도 일회용 번호(nonce)나 상태 검사를 넣어야 할 수 있습니다.

확인 응답과 시간 초과는 서로 반대 방향의 증명을 씁니다

목적 체인이 패킷을 처리하면 확인 응답(acknowledgement) 약정값을 기록하고, 릴레이어가 이를 출발 체인으로 가져옵니다. 확인 응답이 늦다고 해서 목적 체인에서 실행이 실패했다고 단정할 수는 없습니다. 목적 체인에서는 이미 처리됐는데 응답 전달만 늦어지는 경우가 있습니다.

시간 초과는 정해진 높이나 시각까지 목적 체인에서 패킷이 처리되지 않았다는 사실을 증명해 출발 체인에서 실행합니다. 순서 채널의 시간 초과는 채널 상태 자체에 영향을 주므로, 뒤 패킷을 그냥 다시 보내는 것으로는 풀리지 않을 수 있습니다. 비순서 채널에서는 해당 패킷의 시간 초과와 다른 패킷의 수신 기록을 따로따로 볼 수 있습니다.

• 출발 체인의 패킷 약정값과 순번을 확인합니다
• 목적 체인의 수신 기록이나 nextSequenceRecv를 순서 방식에 맞춰 조회합니다
• 확인 응답 약정값과 릴레이 거래를 따로 확인합니다
• 시간 초과 증명이 성립했는지, 채널이 OPEN·CLOSED 중 어느 상태인지 본 뒤 재전송을 정합니다

재전송은 같은 앱 메시지를 새 패킷으로 보내는 일입니다

릴레이어가 같은 패킷 증명을 다시 내는 것과, 사용자가 새 앱 거래를 보내 새 순번을 만드는 것은 다른 일입니다. 앞의 것은 여러 번 해도 결과가 같은 프로토콜 전달을 다시 시도하는 것이고, 뒤의 것은 앱 동작을 두 번 실행할 수 있습니다. 기존 약정값·수신 기록·확인 응답 상태를 보기 전에 새로 보내면 이중 지급이나 중복 주문이 생길 수 있습니다.

순서 채널에 빈 번호가 생겼다면 빠진 순번부터 전달하고, 시간 초과가 이미 처리돼 채널이 닫혔다면 앱이 새 채널 경로를 지원하는지 확인합니다. 비순서 채널도 수신 기록이 있으면 원래 패킷은 이미 처리된 것이니 확인 응답 복구가 먼저입니다. 화면에는 ‘미도착’, ‘처리됨/응답 대기’, ‘시간 초과 가능’을 나눠 보여 줘야 합니다.

선택 기준은 앱이 지켜야 할 불변 조건입니다

토큰 전송처럼 패킷을 하나씩 따로 처리해도 되는 앱은 비순서 채널을 쓸 수 있고, 명령 흐름을 엄격히 지켜야 하는 앱은 순서 채널이 필요할 수 있습니다. 다만 실제 IBC 앱은 해당 모듈 사양과 버전 협상을 따라 정해야 합니다. 처리량만 보고 기존 채널의 순서 방식을 마음대로 바꿀 수는 없습니다.

장애를 분석할 때 핵심은 순서 방식, 순번 상태, 패킷 약정값, 수신 기록·확인 응답, 채널 상태를 한 줄로 엮어 보는 것입니다. 이 다섯 값을 갖춰 두면 ‘11번이 먼저 보였다’는 관찰이 정상적인 비순서 처리인지 순서 채널의 빈 번호인지 가려내고, 안전한 다음 조치를 정할 수 있습니다.

자주 묻는 질문