ORDERED 채널은 목적 체인이 nextSequenceRecv와 정확히 일치하는 packet만 순서대로 받으므로 앞 packet이 비면 뒤 packet도 처리되지 않습니다. UNORDERED 채널은 각 sequence의 receipt 존재 여부로 중복을 막아 서로 다른 packet이 독립적으로 도착할 수 있습니다. ordered 채널에서 packet timeout이 성립하면 채널이 닫히는 규칙이 있어 후속 packet 재전송 전략도 달라집니다.
ordering은 채널 handshake에서 고정된다
IBC classic channel은 열릴 때 ORDERED 또는 UNORDERED ordering을 합의합니다. relayer가 packet을 어떤 순서로 발견했는지 나중에 바꾸는 옵션이 아닙니다. 양쪽 channel end의 counterparty와 ordering, version이 handshake proof로 연결됩니다. 앱은 요구하는 의미에 맞는 ordering을 선택합니다.
sequence는 source port/channel에서 전송할 때 증가합니다. packet에는 source·destination, sequence, timeout과 data가 들어갑니다. 같은 숫자가 모든 채널을 통틀어 전역 순서라는 뜻은 아닙니다. 채널 경로별 sequence를 섞으면 중복이나 gap을 잘못 진단합니다.
IBC ordering은 택배 기사의 도착 순서가 아니라 목적 체인이 받아들일 수 있는 증명의 규칙이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- ordering은 채널 handshake에서 고정된다
IBC classic channel은 열릴 때 ORDERED 또는 UNORDERED ordering을 합의합니다.
- ordered는 빈 번호가 뒤를 막는다
ORDERED 채널의 RecvPacket은 packet sequence가 nextSequenceRecv와 일치하는지 확인합니다.
- ack와 timeout은 반대 방향 proof를 쓴다
목적 체인이 packet을 처리하면 acknowledgement commitment를 기록하고 relayer가 이를 소스 체인으로 가져옵니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
ordered는 빈 번호가 뒤를 막는다
ORDERED 채널의 RecvPacket은 packet sequence가 nextSequenceRecv와 일치하는지 확인합니다. 10을 기다리는 상태에서 11의 proof가 먼저 와도 11을 처리할 수 없습니다. 10이 성공하면 next가 올라가고 11을 받을 수 있습니다. 이 성질은 상태 전이가 순서에 의존하는 앱에 유용하지만 앞 packet 장애가 뒤를 막는 head-of-line blocking을 만듭니다.
UNORDERED 채널은 각 packet sequence의 receipt가 아직 없는지 확인하고 성공 뒤 receipt를 저장합니다. 11을 먼저 받고 나중에 10을 받을 수 있지만 같은 11을 두 번 처리하지 않습니다. 앱 내부 업무 순서까지 자동으로 보장하는 것은 아니므로 data에 별도 nonce나 상태 검사가 필요할 수 있습니다.
| 상황 | ORDERED | UNORDERED |
|---|---|---|
| 10 전, 11 도착 | 11 거부·대기 | 11 receipt 없으면 처리 가능 |
| 같은 11 재전달 | next sequence 불일치 | receipt로 중복 거부 |
| 10 timeout 성립 | 채널 close 영향 | 다른 packet 계속 가능 |
| 앱 업무 순서 | 채널 sequence로 강제 | 앱이 별도 검증 |
ack와 timeout은 반대 방향 proof를 쓴다
목적 체인이 packet을 처리하면 acknowledgement commitment를 기록하고 relayer가 이를 소스 체인으로 가져옵니다. acknowledgement가 늦다고 목적 체인 실행이 실패했다고 단정할 수 없습니다. 목적 체인에는 처리됐지만 ack relay만 지연된 상태가 있을 수 있습니다.
timeout은 목적 체인에서 정해진 높이·시각까지 packet이 처리되지 않았음을 증명해 소스 체인에서 실행합니다. ordered 채널 timeout은 채널 상태에 영향을 주므로 뒤 packet을 단순 재전송해서 해결되지 않을 수 있습니다. unordered에서는 해당 packet의 timeout과 다른 packet의 receipt를 독립적으로 볼 수 있습니다.
- source의 packet commitment와 sequence를 확인한다
- destination의 receipt 또는 nextSequenceRecv를 ordering에 맞춰 조회한다
- acknowledgement commitment와 relay transaction을 별도 확인한다
- timeout proof 성립과 channel OPEN·CLOSED 상태 뒤 재전송을 결정한다
재전송은 같은 앱 메시지를 새 packet으로 보내는 일이다
relayer가 동일 packet proof를 다시 제출하는 것과 사용자가 새 application transaction을 보내 새 sequence를 만드는 것은 다릅니다. 전자는 멱등한 protocol relay를 재시도하는 것이고, 후자는 앱 동작을 중복 실행할 수 있습니다. 기존 commitment·receipt·ack 상태를 확인하기 전에 새 전송을 만들면 이중 지급이나 두 주문이 생길 수 있습니다.
ordered gap에서는 누락 sequence를 먼저 relay하고, timeout이 이미 처리돼 channel이 닫혔다면 앱이 새 channel 경로를 지원하는지 확인합니다. unordered도 receipt가 있으면 원 packet은 이미 처리된 것이므로 ack 복구가 우선입니다. UI는 ‘미도착’, ‘처리됨/ack 대기’, ‘timeout 가능’을 분리해야 합니다.
선택 기준은 앱 불변조건이다
토큰 전송처럼 packet이 독립적으로 처리될 수 있는 앱은 unordered를 사용할 수 있고, 엄격한 명령 스트림은 ordered가 필요할 수 있습니다. 하지만 실제 IBC 앱의 선택은 해당 모듈 사양과 version negotiation을 따라야 합니다. 처리량만 보고 기존 채널 ordering을 임의 변경할 수 없습니다.
장애 분석의 핵심은 ordering, sequence state, packet commitment, receipt·ack, channel state를 한 줄로 묶는 것입니다. 이 다섯 값이 있으면 ‘11이 먼저 보였다’는 관찰을 정상 unordered 처리인지 ordered gap인지 구분하고, 안전한 다음 행동을 정할 수 있습니다.
자주 묻는 질문
unordered 채널은 중복 packet을 허용하나요?
아닙니다. 순서 밖 수신은 가능하지만 sequence별 receipt로 동일 packet의 중복 처리를 막습니다.
ordered 채널에서 2번이 늦고 3번이 먼저 오면 어떻게 되나요?
nextSequenceRecv가 2이면 3은 처리되지 않고 2가 성공한 뒤 다시 relay해야 합니다.
ack가 안 보이면 새 전송을 보내도 되나요?
먼저 목적 체인의 receipt와 acknowledgement를 확인해야 합니다. 실행됐는데 ack relay만 늦은 상태에서 새 전송은 중복 동작을 만들 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
