사소해 보이지만 중요한 이유
제출이 타임아웃된 상황을 생각해 보십시오. 그 주문은 체인에 도달했을까요? 알 수 없습니다. 클라이언트 주문 ID가 없다면 선택지는 최근 주문을 조회해 마켓, 방향, 가격, 수량으로 짐작하거나, 아무것도 하지 않고 잘되기를 바라는 것뿐입니다. 식별자가 있으면 이 모호함이 사라집니다. 직접 생성한 식별자로 취소를 보냅니다. 주문이 존재했다면 취소되고, 애초에 도달하지 않았다면 취소 요청은 아무것도 찾지 못합니다. 어느 쪽이든 상태가 확정된 채로 끝납니다. 사람이 지켜보지 않는 시스템에 실제로 필요한 것이 바로 이 확정입니다. 대조 작업이 감당 가능해지는 것도 같은 이유에서입니다. 자체 기록이 직접 부여한 식별자를 키로 삼으므로, 자기 쪽 장부와 체인의 기록을 맞춰 보는 일이 추정이 아니라 단순 조회가 됩니다.형식
식별자는 16바이트 값이며,0x로 시작하는 32자리 소문자 16진수 문자열로 제출합니다.
- 소문자만 허용. 대문자 16진수는 정규화되지 않고 거부됩니다.
- 길이 고정. 더 짧거나 더 긴 값은 거부됩니다.
- 전부 0인 값은 예약됨.
0x00000000...0000은 없음을 뜻하는 센티널 값이므로 식별자로 쓸 수 없습니다.
고유성
고유성의 범위는 서브 계정입니다. 서명 주소와 그 아래의 서브 계정 조합 단위로 적용됩니다. 여기서 두 가지가 따라옵니다. 같은 주소 아래의 서로 다른 서브 계정은 충돌 없이 같은 식별자를 쓸 수 있습니다. 각자 ID를 생성하는 독립 전략을 여러 개 돌릴 때 쓸모가 있습니다. 반대로 한 서브 계정 안에서 아직 살아 있는 주문의 식별자를 다시 쓰면, 대체가 아니라 오류입니다.식별자는 순차적으로가 아니라 무작위로 생성하십시오. 카운터는 순서가 눈에 보인다는 점에서 끌리지만, 카운터 값을 잃은 채 재시작하면 아직 살아 있는 주문과 충돌합니다. 무작위 16바이트는 실무에서 충돌하지 않습니다.
할 수 있는 일
수명
식별자는 세션이 아니라 주문에 귀속됩니다. 주문이 체결되거나 취소된 뒤에도 계속 조회할 수 있으며, 사후 대조에 쓸모가 있는 것은 그 때문입니다. 식별자가 가리키던 주문이 더 이상 활성 상태가 아니면 그 식별자를 다시 쓸 수 있습니다. 다만 실무에서 재사용할 이유는 거의 없습니다. 새 무작위 값을 만드는 데는 비용이 들지 않고, 과거 기록이 어느 주문을 가리키는지 헷갈릴 일도 없습니다.다음으로 읽을 문서
주문 수정
활성 주문을 변경할 때 그 식별자에 어떤 일이 생기는지 설명합니다.
주문 유형
식별자를 붙일 수 있는 대상을 다룹니다.
개발자
코드에서 주문을 제출하고 모호한 응답을 처리하는 방법을 다룹니다.
트랜잭션 시퀀싱
같은 블록에 제출된 취소가 유동성을 가져가는 주문보다 먼저 실행되는 이유를 설명합니다.