원문 제목: "거래 플랫폼의 무한한 화폐 발행 비밀: 암호화 현물부터 계약, 옵션, 예측 시장의 주문 매칭 엔진 해설"
원문 저자: danny, 암호화 분석가

바이낸스 스팟 및 퍼피추어스를 여는 순간, 주문서는 거의 동일합니다. 그러나 "매도" 순간에는 뒷면에 완전히 다른 두 개의 메커니즘이 있습니다.

퍼프는 왜 두 가지 가격을 유지해야 하나요? 왜 아이언 콘더는 네 다리가 동시에 매매되어야 하나요? 왜 예측 시장의 수수료는 p=0.5일 때 가장 비싼가요? 이러한 질문들은 표면적으로 메커니즘을 묻는 것처럼 보이지만, 본질적으로는 같은 것을 묻고 있습니다 — 매칭 엔진은 결코 독립형 엔지니어링 모듈이 아니며, 이는 서비스하는 자산에 의해 형성됩니다.

현물, 퍼피쳐, 옵션, 예측 시장의 네 가지 형태 사이의 차이는 유사성보다 깊습니다. 이 글에서는 그들을 해체하여, 무엇이 그들을 "매칭"을 거의 관련이 없는 엔지니어링 실체들로 만드는 힘인지 분명히 합니다.

일. 매칭은 표준 부품이 아닙니다

현물 거래의 매칭 구현만 본 적이 있다면, "매칭 엔진"은 성숙하고, 수렴하며 기술적인 내용이 거의 없는 것으로 생각할 수 있습니다 — 주문서 정렬, 가격-시간 우선 매칭 루프, 그리고 일회성 결제 경로가 있는 end of the story.

하지만 그것은 큰 오산입니다...

Coinbase의 BTC/USDT에서 바이낸스의 BTCUSDT 퍼피추어스 계약으로, 다음으로 Deribit의 BTC-26DEC25-50000-C까지 이동한 후 Polymarket에서 어떤 이벤트 시장까지 이동하면, 이 네 개 시장 뒤에 있는 매칭 엔진이 구조적으로 거의 다른 네 가지 다른 기계임을 알게 될 것입니다.

그들은 어떤 알고리즘적 유사성을 공유하지만, 상태 머신, 리스크 관리 결합, 거래 경계, 신뢰 가정 등의 측면으로 들어가면, "매칭 엔진"이라는 용어가 지나치게 추상적으로 보일 정도로 차이가 큽니다.

이 글이 하고 싶은 것은 이 네 가지 전형적인 형태를 분해하여, 같은 기본 개념이 서로 다른 엔지니어링 실체로 어떻게 분화되었는지 명확히 하는 것입니다.

이. 현물 매칭: 가장 기본적인 형태

현물 매칭은 표준 모델이며, 거의 모든 교과서와 오픈 소스 프로젝트(LMAX Disruptor, CME Globex의 간소화된 버전, 다양한 오픈 소스 매칭 엔진)가 여기서 시작됩니다.

핵심 데이터 구조는 일반적으로 두 개의 가격 트리(매수 측, 매도 측)이며, 각 가격 노드에는 FIFO 큐가 있습니다. 매칭 루프는 매우 직관적입니다. 먹는 주문(taker)이 도착하면 상대편의 최상위 가격 대략부터 스캔하여 시간 순서에 따라 메이커 큐를 소비할 때까지 먹는 주문 수량이 소진되거나 가격이 한정가를 넘을 때까지 진행됩니다.

핵심 특징에는 몇 가지 핵심 포인트가 있어서 별도로 언급할 가치가 있습니다:

첫째, 자산이 동질적이고 분할 가능한 특성입니다. 매수자는 견적 자산(USDT)을 보유하고, 매도자는 기초 자산(BTC)을 보유하며, 매칭의 본질은 한 번에 자산 교환입니다. 원장 상의 작업은 거래와 연결된 쌍의 잔액 조정입니다. 결제와 매칭이 동일한 거래 내에서 이루어집니다. 매칭 엔진에는 외부 종속성이 거의 필요하지 않습니다. 매칭은 결제이며, 하부 연결이 없습니다.

둘째, 위험이 즉각적으로 청산됩니다. 현물 거래가 완료되는 즉시 모든 포지션 관계가 사라지며, 매칭 레이어에서는 '포지션'이라는 개념이 계속되지 않습니다. 엔진은 가격 변동으로 인한 청산을 걱정할 필요가 없습니다. '포지션'이라는 것은 사실상 존재하지 않습니다.

셋째, 주문 유형은 상대적으로 수렴됩니다. Limit, Market, IOC, FOK, Post-only, Stop—이러한 것들은 주문 수명 주기 관리의 변형입니다.

구체적인 시나리오를 들어보겠습니다. BTC/USDT 매도 1단계 50,001 × 1.5 BTC(maker A는 09:30:00.100에 주문을 등록), 매도 2단계 50,002 × 3.0 BTC(maker B는 09:30:00.200에 1.0을 등록, maker C는 09:30:00.300에 2.0을 등록).

4.0 BTC의 시장가 주문이 도착합니다. 매칭 루프: 먼저 A가 50,001에서 전체 1.5에 대해 매치되고, 다음 단계로 넘어가서 FIFO 순서로 진행됩니다. B가 C보다 먼저이며, B가 50,002에서 전체 1.0에 대해 매치되며, 그 다음 C의 일부 1.5가 매치됩니다(C가 0.5를 남깁니다).

먹는 주문 계정은 한 거래에서 200,006.5 USDT를 차감하고 4.0 BTC를 추가하며, 세 개의 메이커 계정이 대응되어 업데이트됩니다. 이러한 일련의 작업은 데이터베이스 트랜잭션 내에서 수행되며, 매칭은 결제입니다. B가 C보다 선행되는 이유는 가격이 아니라(동일한 단계임) 먼저 주문을 등록했기 때문입니다. 이것이 price-time 우선순위의 실제적인 반영입니다.

현물 매칭 엔진에서의 난점은 실제로 논리에 있지 않고 성능에 있습니다. 백만 거래/초의 TPS에서 마이크로초 지연을 유지하는 방법, 캐시 지역성 처리, 결정론적 재생을 어떻게 하는가 하는 것이 어렵습니다. 그러나 이러한 것들은 최적화 문제이며, 메커니즘 문제가 아닙니다.

3. 퍼피추얼스 매칭: 리스크 엔진의 침투

바이낸스 퍼피추얼스 계약의 주문서를 현물 주문서 옆에 놓고 보면 시각적으로 차이를 알아챌 수 없을 것입니다. 그러나 밑바닥에서는 전혀 다른 이야기입니다.

주요 변화는 다음과 같습니다: 매칭 엔진은 결제의 종착지가 아니라 이벤트 원천입니다. (또는 도미노 타일)라고도 불릴 수 있습니다.

각 퍼프 매칭 완료마다 복잡한 다운스트림 체인이 트리거됩니다: 표시 가격 업데이트, 포지션 업데이트, 마진 재계산, 미실현 손익 갱신, 가능한 청산 트리거. 매칭 엔진과 리스크 엔진은 퍼프에서 깊게 결합되어 있으며, 결합 방식이 전체 시스템의 특성을 결정합니다.

이중 가격 체계는 퍼프의 첫 번째 독특한 구조입니다. 매칭 자체는 여전히 "최근 거래 가격"에 따라 작동하지만, 유지 마진, 청산 트리거, UPnL 계산에는 "표시 가격"을 사용하며, 이는 여러 현물 시장의 가중 평균 가격에 펀딩 조정을 더한 값입니다. 이것은 조작에 대한 디자인입니다. 매칭 가격과 표시 가격이 일치하면 공격자가 주문서를 극단가로 끌어당겨 반대 포지션의 청산을 즉시 발생시킬 수 있습니다. 이중 체계는 이러한 공격 가능성을 제거합니다.

구체적인 시나리오를 들어보겠습니다. 어떤 거래자가 50배 롱으로 1 BTC를 거래했고, 60,000에 진입했으며, 초기 마진은 1,200 USDT이며 유지 마진은 300 USDT입니다. 한 순간 주문서는 대량 시장가 주문으로 마지막 가격 = 58,500까지 즉시 돌파되었습니다. 마지막으로 계산하는 경우 미실현 손실은 1,500 USDT이므로 청산되었습니다.

그러나 동시에 표시 가격은 (다중 현물 지수 가중치 + 펀딩 조정) = 59,400로, 이 표시에 따라 계산하면 600 USDT의 미실현 손실이 발생하고 계정 잔고가 600으로 유지 마진인 300을 초과하여 청산이 트리거되지 않습니다. 몇 초 후에 마지막 가격이 59,400으로 돌아오면 이 거래자는 청산되지 않았습니다.

매칭 및 청산이 동시에 마지막 가격을 사용하는 경우, 공격자는 작은 자금으로 주문서가 취약한 시점에 가격을 극단적으로 조작하여 반대 방향의 포지션 체인 청산을 유도하고 낮은 가격으로 다시 매입할 수 있습니다. 이것은 바로 BitMEX 초기에 빈번하게 발생한 이벤트 유형입니다. 이중 기구는 '정확성을 위해'가 아니라 '공격을 피하기 위해'입니다.

거래 전 리스크 관리는 또 다른 중요한 삽입 지점입니다. 현물에서는 틱이 도착하면 직접 매칭됩니다. 반면 퍼프 거래에서 틱이 먼저 보증금 확인을 거쳐야 합니다. 현재 사용 가능한 보증금으로 이 거래로 인한 포지션 변경을 커버할 수 있는지 확인합니다. 크로스 마진 모드인 경우, 이 확인은 계정 내 모든 포지션의 상호 헷지를 고려해야 합니다. 이 확인은 매칭 루프 내에서 동기화되어 완료되어야 하며 그렇지 않으면 '거래 후 보증금 부족'과 같은 일관성 없는 상태가 발생합니다.

특수 청산 매칭 채널은 퍼프 엔진의 가장 흥미로운 부분입니다. 계정 유지 증가율이 유지 마진을 하회하면 청산 엔진이 작동합니다. 이 엔진은 계정의 파산 가격(또는 특정 보호 가격)으로 IOC 주문을 주문서로 전송하여 포지션을 정리하려고 시도합니다. 주문서가 너무 얇으면 이 청산 주문을 소비할 수 없는 경우 어떻게 해야 하나요? 여기에는 몇 가지 엔지니어링 옵션이 있습니다. 보험 기금에 접근하여 보전하거나, ADL(자동 감소)을 트리거하여 시스템이 이익을 취한 상대방의 포지션을 강제로 축소시킵니다.

ADL은 본질적으로 '매칭의 마지막 링크'입니다. 주문서 및 보험 기금이 모두 실패한 경우, 시스템은 주문서를 건너뛰고 두 계정 간에 강제로 결제합니다. 이것은 '의사 매칭'에서 '비의사 매칭'으로 매칭 개념을 확장한 설계입니다. 이것은 이미 전통적인 의미의 매칭이 아니지만 존재해야 하며, 그렇지 않으면 시스템은 극단적인 시장 상황에서 파산할 수 있습니다.

자체 거래 방지(STP)의 복잡성도 퍼프의 특징입니다. 현물에서 자체 거래 방지는 세탁 거래를 방지하는 데 중점을 둡니다. 그러나 퍼프에서는 동일한 계정이 롱 포지션과 숏 포지션을 동시에 보유할 수 있기 때문에 STP의 의미를 세분화해야 합니다. 서브 계정, 사용자 ID 또는 마스터 계정별로 나눠야 하는가는 각 거래 플랫폼마다 다릅니다.

요약하면, 퍼프 매칭의 '어려움'은 주문서 자체가 아니라 그 뒤에 바인딩된 전체적인 리스크 엔진과 상태 머신에 있습니다. 디자이너는 명확하게 생각해야 합니다: 어떤 점검이 매칭 주요 경로에서(동기적으로) 이루어져야 하고, 어떤 것이 비동기적으로 이루어져야 하는가; 청산 실행 모델은 무엇인가; 보험 기금은 어떻게 충당하는가; ADL 트리거 우선 순위 큐는 어떻게 정렬되는가(일반적으로 '이익 비율 × 레버리지 배수'로 정렬하여, 가장 이윤이 많고 레버리지가 높은 사람이 우선적으로 청산되도록 함).

4. 영구적인 매칭의 이중 경로: 의사 결정, 구성, 실행의 층

영구적 매칭은 논의할 가치가 있는 또 다른 층이 있습니다. 이 매칭 경로는 매칭 단계와 일반 주문이 통합되지만 통합 전후에는 완전히 다른 논리가 적용됩니다. 이 층의 이해는 영속 엔진을 설계하거나 디버깅하는 데 매우 중요합니다. 그렇지 않으면 "매칭"과 "청산"의 경계를 계속 혼동하게 될 것입니다.

청산을 세 가지 층으로 분해해 보겠습니다:

첫 번째 층은 트리거 판단입니다. 마크 가격을 사용하여 판단되는 이유는 "청산해야 하는가"에 대한 의사 결정이 주문 대장의 즉각적 조작에 영향을 받지 않도록하기 위함입니다. 이 층은 거래소 내부 딥스탠드를 완전히 떠난 독립적인 리스크 컨트롤 판단입니다.

두 번째 층은 주문 구성입니다. 청산 엔진이 청산을 결정하면 IOC 주문을 생성하여 주문 대장에 보냅니다.

이 주문 및 사용자의 일반 주문은 여러 측면에서 구조적으로 다릅니다. 가격은 사용자가 선택한 것이 아니라 엔진이 파산 가격을 제한 가격으로 삼음. 유형은 항상 IOC로 rest in book을 허용하지 않음. 수수료는 청산 수수료율(0.5-1.5%)을 따르고 taker 수수료율이 아니며 보험 기금으로 가고. 주문 권한은 계정이 아닌 시스템에 속함 - 계정은 청산될 때 심지어 대기 중인 모든 주문을 먼저 철회해야 함(자가 거래 오염을 방지하기 위해) 이중 처리 실패는 다르다 - 사용자 IOC는 수행되지 않고 사라지며, 청산 IOC가 수행되지 않으면 보험 기금 활성화 → ADL의 연쇄.

세 번째 층은 매칭 실행입니다. 주문 대장에 들어가면, 청산 IOC 및 일반 IOC는 상대편 유동성을 먹이기 위해 동일한 price-time 우선순위 규칙을 따릅니다. 이 층은 대칭적이며, 매칭 엔진은 청산 주문을 특별 취급하지 않습니다 - 매칭 사이클에 if-else가 있으면 결정론적 재생을 파괴하게 됩니다.

따라서 정확한 설명은 다음과 같습니다: 매칭 사이클 자체는 두 개 그룹으로 분리되지는 않지만, 주문의 출처, 구성, 요금부과, 실패 경로는 분리됩니다. 매칭 주요 경로의 관점에서 보면, 청산 및 일반 주문은 동등합니다. 거래 내역의 전경으로 보면, 이러한 주문들은 두 개의 평행 파이프 라인을 따라 이동하며 매칭 단계에서만 통합됩니다.

여기에 주목할 만한 한 가지 더 있는데요- 마크 가격은 "어떤 가격으로 청산되어야 하는가"를 결정(트리거 조건)하지만, 최종 가격(거래소 딥스탠드)은 "실제로 어떤 가격으로 청산될 수 있는가"를 결정합니다. 주문 대장이 얇아지고 깊이가 사라지면, 청산 IOC가 대가를 지불하는 실제 체결 가격이 파산 가격보다 훨씬 낮을 수 있습니다. 이 차이가 바로 보험 기금의 "손익 요소"입니다. 보험 기금은 "마크가 제시하는 이론적 청산 가격"과 "거래소에서 실행된 실제 체결 가격" 간의 편차를 흡수합니다. 둘 다 항상 일치한다면 보험 기금은 실제로 존재할 필요가 없습니다.

보다 진보적인 디자인(이른바 dYdX의 초기 backstop liquidator 네트워크)은 단순히 주문대장 앞에 "청산 경로와 독립적인 상대방 채널"을 추가했습니다 — backstop 보트나 화이트리스트 청산자가 전체 포지션을 우선 처리하도록하고 주문대장이라는 느린 경로를 우회합니다. 이것은 본질적으로 "강제 청산 실행"을 거래소 내부 짝 맞춤에서 완전히 분리하여 청산 경로의 자체 짝 맞춤 채널을 제공하는 것입니다. 이것은 이중 경로 문제에 대한 또 다른 대답 방법입니다: 일부 거래소는 두 경로를 동일한 주문대장에 넣는 것이 타협이라고 생각하여 서로 다른 짝 맞춤 채널을 사용하도록 하였습니다.

perp 짝 맞춤 복잡성의 핵심으로 돌아가면: 짝 맞춤 메인 루프 자체는 간결하게 유지될 수 있지만, 그 주변의 상태 머신 — 리스크 관리, 청산, 보험 기금, ADL, 아마도 backstop liquidator 네트워크 — 는 주문대장 자체보다 훨씬 복잡한 시스템을 형성합니다.

실제로는 "주문대장이 현물과 같이 크게 생겼다"는 시각적 인상 속에는 두 개의 독립적인 입장 채널과 네 가지 다른 탈출 경로가 있습니다. 이것이 perp 매칭의 "어렵다"의 실제 모습입니다. (일부 거래소에서 여전히 b book을 사용하는 것으로 알려져 있음)

다섯 번째, 옵션 매칭: 그리드 및 시장 메이커 중심

옵션은 이 네 가지 자산 유형 중에서 유일하게 "기초 자산 자체가 폭발적인 수량을 가지고 있는" 범주입니다. BTC 현물 시장에는 주문대장이 하나뿐이며, BTC 퍼펫도 하나뿐입니다. 그러나 BTC 옵션 — Deribit을 예로 들면 — 언제든지 수백 개의 활성 계약이 있고, strike × 만기 × 콜/풋이라는 세 가지 차원으로 조합됩니다. 각 계약에는 독립적인 주문대장이 필요합니다.

이것은 첫 번째 핵심적인 문제를 야기합니다: 유동성 부족. 깊은 인더머니 또는 아웃더머니 계약은 하루에 몇 거래만 있을 수 있으며, 주문대장은 종종 비어 있거나 시장 메이커의 두 개 매수/매도 주문만 있습니다. 이러한 희박성으로 인해 순 LOB 모델은 거의 사용할 수 없습니다 — 일반 구매자가 한정가 주문을 내며 몇 일이 지날 때까지 거래가 성사되지 않을 수 있습니다.

업계의 해결책은 세 가지 모드를 혼합하는 것입니다:

LOB는 가장 깊은 유동성 계약에 사용됩니다，주로 ATM 옵션 및 근월물 계약입니다. 이 부분은 현물 논리와 본질적으로 동일합니다.

RFQ(Request For Quote)는 유동성 부족한 계약에 사용됩니다. 거래자가 가격 요청을 보내면, 여러 시장 메이커가 응답하고 거래자가 최상의 것을 선택합니다. 이 프로세스는 LOB 외부에서 실행되며, 매칭은 "견적 요청 vs 여러 견적 응답"으로 이루어지며 본질적으로 역경매입니다.

블록 거래(Block trade, 大宗 거래)은 대규모 주문에 사용됩니다. 두 상대방이 장외에서 가격을 합의하고 거래를 거래 플랫폼에 신고하여 결제를 진행하며, 주문서는 매칭에 참여하지 않고 단순히 등록만 합니다.

다리 다리 동기화 매칭(Multi-leg Sync Matching)은 옵션 매칭의 또 다른 핵심 요소입니다. 널리 쓰이는 전략인 아이언 컨더(Iron Condor)와 같이 네 가지 서로 다른 옵션 계약을 동시에 매매해야 하는 경우가 있습니다. 만약 네 다리가 각각 네 개의 주문서에서 독립적으로 매칭된다면, 두 다리는 체결되었지만 나머지 두 다리는 미체결일 수 있으며, 거래자의 리스크 노출은 전혀 바라는 대로가 아닐 것입니다.

따라서 옵션 매칭 엔진은 콤보 주문서북(Combo Book)이나 다중 다리 원자적 실행(Multi-Leg Atomic Execution)을 지원해야 합니다. 네 다리는 전부 체결되거나 전부 미체결되어야 하며, 이를 전체적으로 처리해야 합니다.

Deribit의 방식은 현재 산업 표준으로 볼 수 있습니다. Deribit은 독립적인 콤보 주문서북을 갖고 있으며, 콤보 주문은 개별적으로 주문될 수도 있고, 단일 다리 주문서북과 암시적 매칭을 수행할 수 있습니다. 시스템은 자동으로 단일 다리 유동성에서 콤보 가격으로 합성하거나 그 반대로도 수행합니다. 이는 매우 정교한 설계이지만, 매칭 주요 경로에서 '가상 주문서북' 상태를 동기화해야 한다는 것을 의미합니다.

구체적인 시나리오를 예로 들어보겠습니다. 이론상 ETH의 현재 가격이 3,000이고, 거래자는 미래 7일 동안 [2,900, 3,100] 범위에서의 변동을 예상하여 아이언 컨더를 구성합니다: 3,100 콜 매도, 3,200 콜 매수, 2,900 풋 매도, 2,800 풋 매수. 네 다리의 순 보상은 전략의 최대 수익을 나타내며, 최대 손실은 보호 다리가 엄격히 상한선을 갖기 때문에 설정된 전제조건입니다.

네 주문이 각각 네 개의 주문서에 개별적으로 제출되어 매칭되는 경우, 가장 흔한 실패 시나리오는 다음과 같습니다: 처음 두 주문(콜 스프레드 부분)이 체결되었고, ETH의 가격이 2,950으로 급등한 후 뒤이어 두 주문(풋 스프레드 부분)의 상대방 가격이 더 이상 유효하지 않으며, 물량 공급 업자가 주문을 철회하거나 크게 조정하여 C 및 D가 체결되지 않았습니다. 결과적으로 거래자는 매수된 콜 스프레드만 가지고 있게 되어 방향성 노출이 전혀 반대로 되었고, 원래의 '변동 수익' 전략이 '하락 손실' 전략으로 변하며, 최대 손실 또한 더 이상 제한되지 않습니다.

콤보 주문서북은 네 다리를 하나의 통합체로 처리합니다: 전부 체결되거나 전부 체결되지 않거나. 암시적 매칭은 단일 다리 주문서북의 유동성을 실시간으로 합성하여 콤보 가격을 만들어내며, 그 반대의 경우에도 콤보 주문서북의 유동성을 단일 다리로 돌려놓음으로써 두 계층의 유동성이 상호 보완됩니다.

메이커의 가격 책정 알고리즘은 주로 IV Implicit Volatility을 사용하며, 가격이 아닙니다 (이는 옵션 특유의 특성입니다). 메이커는 "50000 strike call $1500"을 올리지 않을 것이며, 대신 "65 vol에서 매수, 67 vol에서 매도"를 올릴 것입니다. 시스템은 각 견적이 활성화될 때마다 현재 기초 자산 가격을 사용하여 BSM(블랙-숄즈-머튼 모형) (또는 보다 복잡한 모델)을 사용하여 실제 견적을 계산합니다.

이는 메이커의 견적이 기초 자산을 동적으로 따르게 함을 의미하며, 기초 자산 가격이 변경될 때 주문서가 자동으로 조정됩니다. 이로 인해 옵션에서 "지정가 주문"이 이산적인 이벤트가 아닌 연속 함수로 변하게 됩니다.

그리스식으로 변환된 포트폴리오 마진은 리스크 관리를 다르게 만듭니다. Perp에서는 각 포지션에 대해 독립적으로 마진을 계산하며, 옵션에서는 메이커가 수백 개의 계약을 동시에 보유할 수 있기 때문에 각 계약에 대해 개별적으로 마진을 계산하는 것은 자본 효율성을 떨어뜨려 영업이 불가능하게 합니다.

그래서 옵션 거래 플랫폼은 일반적으로 그리스 문자(델타, 감마, 베가, 세타)를 기반으로 하는 포트폴리오 마진을 채택하여 전체 포트폴리오를 순 노출로 보고 순 그리스에 따라 마진을 계산합니다. 이는 다시 거래 매칭에 영향을 줍니다. 한 거래의 "마진 비용"은 이미 보유한 포지션을 헷지했는지에 따라 달라집니다.

6. Polymarket 매칭: 온체인-오프체인 혼합 아키텍처

이전에 논의하기 전에 가능한 의문에 대답하겠습니다. Polymarket을 별도로 다루는 이유는 무엇인가요? 왜 AMM에 대해 논의하지 않고이를 일반화 된 "DEX 매칭" 범주에 통합하지 않나요?

그 이유는 Polymarket의 독특함이 "온체인"이라는 레이블에 있지 않기 때문입니다. Polymarket의 진정한 독특한 점은 세 가지 매커니즘의 중첩입니다: [0, 1] 가격 컨스트레인트 + CTF 보완적 발행 + UMA 결과 판단(마크 가격 유사). 이 세 가지가 함께 하나로 결합되어 현물, 퍼프, 옵션 및 기타 DEX와는 다른 상태 기계 양상을 형성합니다 - 가격 공간은 이산적이고 한정되어 있으며, 유동성이 창출되며, 수명주기에 종점이 있습니다.

아래에서는 이 세 가지 기제 및 그에 대한 신뢰 가정을 중심으로 살펴보겠습니다.

Polymarket은 Polygon 상에 구축된 최초의 예측 시장으로, 모든 포지션은 ERC-1155 토큰이며 Gnosis의 Conditional Token Framework(CTF)에 의해 발행됩니다. 하나의 시장 — 예를 들어 어떤 대통령 선거에 대한 이진 예측 —은 YES 토큰과 NO 토큰을 발행하며, 시장이 종료될 때 한 가지 토큰은 $1의 가치를 가지고 다른 하나는 $0의 가치를 갖습니다.

보완적 발행 메커니즘은 CTF의 핵심입니다. 누구나 1 USDC를 예치하여 1 YES + 1 NO를 받을 수 있습니다. 누구나 1 YES + 1 NO를 소멸시켜 1 USDC를 인출할 수 있습니다. 이 메커니즘의 존재로 인해 유동성 공급자는 시장에 유동성을 제공할 수 있으며 유동성 공급자는 토큰을 보유하지 않은 상태에서도 판매할 수 있습니다. 유동성을 제공하기 위해 토큰을 미리 보유할 필요가 없습니다. 그는 즉시 발행한 다음 판매할 수 있습니다. 매칭 엔진의 관점에서, 이는 유동성 공급자가 초기 무제한 재고를 보유한 것과 동등하지만 비용 제한은 마진 내에 있음을 의미하여 이것은 Polymarket과 전통 CLOB 간의 주요 차이점 중 하나입니다.

오프체인 매칭 + 온체인 결제는 Polymarket의 전체 아키텍처입니다. 구체적인 프로세스는 사용자가 EIP-712로 한정가 주문을 서명하고 Polymarket의 중앙 집중식 매칭 서버로 전송함; 서버는 전통적인 LOB를 유지합니다; 두 주문이 일치할 때, 서버는 두 서명을 하나의 온체인 거래로 패키징하고 결제를 완료하기 위해 교환 스마트 계약을 호출합니다. 따라서 매칭 자체는 오프체인(밀리초)이지만 결제는 온체인(초)입니다.

이 아키텍처는 신뢰 측면에서 특별한 특징을 가지고 있습니다: 매칭 서버는 거래를 위조할 수 없습니다 사용자의 개인 키가 없기 때문에; 그러나 거래를 검토할 수 있습니다 — 일부 주문을 매칭에서 거절할 수 있습니다.

가스 경제학은 사용자 행동이 아닌 결제 경로를 형성합니다. 일반적인 오해는 Polymarket의 가스 비용을 사용자에게 귀속한다는 것입니다 — 실제로 가스는 relayer(Polymarket의 운영자)가 지불합니다. 사용자는 EIP-712로 주문을 서명하고, relayer는 매칭 후 체결을 위해 거래를 일괄 제출하며, 가스는 Polymarket이 부담하고 거래 수수료를 통해 회수됩니다. 이는 사용자에게 주문 및 철회가 무료임을 의미합니다. — 철회는 심지어 전혀 온체인이 아니며, 주문을 제거하도록 매칭 서버에 통보할 뿐입니다. 논리적으로 CEX 주문을 취소하는 것과 본질적인 차이가 없습니다.

그러나 이는 gas가 제한적이지 않다는 것을 의미합니다. 오히려 제한이 relayer 쪽으로 이동했습니다. 각 거래의 체인 상 정산 비용은 Polymarket이 부담하며, relayer의 gas 예산과 Polygon의 처리량 상한이 시스템의 최대 거래 빈도를 결정합니다. 유동성 제공자가 극단적으로 혼잡한 상황에서 겪는 것은 「거래 비용이 비싸다」가 아니라 정산 지연과 처리량 병목 현상입니다. 이는 CEX와는 완전히 다른 혼잡 전파 경로입니다.

이 아키텍처가 거래 매칭 엔진에 부과하는 실질적인 형태는 다음과 같습니다. relayer가 여러 거래를 일괄 처리할 수 있도록 하는 동시에 각 거래를 정산 스마트 계약에서 개별적으로 확인할 수 있어야 합니다(가짜 relayer나 자금 도용을 방지하기 위해).

따라서 Polymarket의 거래소 스마트 계약은 「다중 서명 주문 + 일괄 제출 거래」 구조를 수용하도록 설계되었습니다. Gas로 인해 Polymarket이 「저주파 거래소」로 전락하는 것이 아니라, 매칭-정산 결합 방식이 CEX와 순수 체인상 DEX와는 다르다는 점입니다. 매칭 계층은 CEX의 경량화를 완전히 계승합니다(밀리초 주문 취소, 제로 gas 주문), 그러나 정산 계층은 체인상 DEX의 확인 가능성 제약을 계승합니다.

오라클 결과의 최종성은 예측 시장 매칭의 가장 특이한 측면입니다. 다른 세 가지 시장 분류는 모두 계속해서 운영됩니다. 즉, 가격은 항상 변동하고 시장은 항상 열려 있습니다. 그러나 예측 시장은 명확한 「종료 시간」을 가지고 있습니다. 이벤트가 발생하고 결과가 Oracle(UMA의 낙관적 오라클을 사용하는 Polymarket)에 의해 해결되면 YES 또는 NO로 확정되며, 모든 보유자는 1:0 또는 0:1로 정산됩니다.

이는 매칭 엔진이 「시장 동결」 상태 기계를 처리해야 한다는 것을 의미합니다. 해결 윈도우 내에서 새 주문을 금지하고, 분쟁 윈도우 내에서 챌린지를 허용하며, 최종적으로 모든 거래 활동을 중단해야 합니다. 이 상태 기계는 CEX 스팟 시장에는 해당하지 않습니다.

가격이 [0, 1] 범위로 제한되는 것은 또 다른 메커니즘 제약입니다. 이는 장점으로 보일 수 있지만(무한히 폭파되지 않음), 주문서의 가격 단계 공간이 제한된다는 것을 의미합니다. 일반적으로 1 센트 당 1 단계, 최대 100 단계입니다. 이는 매칭 데이터 구조에 강력한 제약을 가지고(트리 대신 고정 크기 배열 사용 가능) 가격 발견의 정밀도에 한계가 있음을 의미합니다.

모든 차원은 매칭 엔진에 압력을 가합니다:

자산 모양은 주문 대장의 수량과 희소성을 결정합니다. 단일 차원 동질(현물, 미래)은 단일 대장만 필요하며, 다차원 희소(옵션)는 수백 개의 대장이 필요하며 희소성을 해결해야 합니다. 이산 보완(Polymarket)은 "주조/상환"을 매칭 경로에 통합해야 합니다.

결제 타이밍은 상태 머신의 복잡성을 결정합니다. 즉각적 동기화(현물)는 매칭을 결제로 동일하게 만듭니다. 지속 기록(perp, 옵션)은 포지션 상태, 마진 상태, PnL 상태를 유지하고 매 매칭 후에 업데이트해야 합니다. 최종 해결(Polymarket)은 상태 머신이 "오픈"에서 "동결"로, 그리고 "해결"로 전환해야 합니다.

위험 토폴로지는 리스크 커플링을 결정합니다. 선형 무 포지션(현물)은 거의 리스크 관리가 필요하지 않습니다. 선형 지속적 노출(perp)은 선 거래 마진 체크와 청산 엔진이 필요합니다. 볼록(옵션)은 그리스 기반의 결합 마진이 필요합니다. 이항 유계(prediction)은 거의 리스크 관리가 필요하지 않습니다(최대 손실은 이미 지불된 금액입니다).

유동성 밀도는 유동성 소스 전략을 결정합니다. 고밀도 시장은 순수한 LOB만으로 충분합니다. 희소 시장은 RFQ, AMM, 메이커 인센티브 등 보충 메커니즘을 도입해야 합니다.

신뢰 경계는 어떤 구성 요소가 검증 가능해야 하는지를 결정합니다. CEX의 경우 모든 구성 요소가 거래 플랫폼 내부에 있습니다. 순수 DEX의 경우 모든 구성 요소가 체인 상에 있습니다. 혼합 구조의 경우 무엇을 체인 상에 두어야 하는지(결제), 무엇을 오프 체인(매칭)으로 남겨야 하는지, 공격 모델이 무엇인지(자금 도난은 불가능하지만 감사 가능)를 명확히해야 합니다.

팔. 한 걸음도 낭비되지 않는다: 매칭은 메커니즘의 거울이다

처음 문제로 돌아가면, 왜 "매칭 엔진"이 다른 시장에서 거의 다른 네 가지 기계로 분화되는가요?

그것은 매칭이 결코 독립적인 엔지니어링 모듈이 아니라 자산 자체의 성격, 결제 모델, 리스크 구조, 유동성 형태, 신뢰 가정이라는 다섯 변수의 종합이 결과로 작용했기 때문입니다. 매칭 엔진은 이러한 변수의 모습입니다-매칭이 어떻게 생겼는지를 보면 해당 시장의 금융 구조가 어떻게 생겼는지를 유추할 수 있습니다.

현물 매칭의 간결함은 "동질 자산 + 일회성 결제 + 제로 포지션 롤오버"의 깔끔한 구조에 해당합니다;

무기한 계약 매칭의 복잡함은 "합성 자산 + 지속적 노출 + 리스크 관리-매칭 깊게 결합"의 공학적 현실에 해당합니다;

옵션 매칭의 혼합 형태는 "차원 폭발 + 유동성 부족 + 메이커 중심"의 시장 구조에 해당합니다;

Polymarket 매칭의 온체인-오프체인 분리는 "무 검열"과 "도난 방지"라는 두 보안 목표의 공학적 타협에 해당합니다.

청산이 거래 플랫폼의 양심이라면, 매칭 메커니즘은 거래 플랫폼의 바닥선입니다.

원문 링크

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia