Розробка DEX на базі order book

Розробка DEX на базі книги ордерів

Order book DEX — це децентралізована біржа, що використовує модель книги ордерів замість AMM-пула. Трейдери виставляють limit ордери, matching engine їх зводить. Принципове питання: де живе order book і де відбувається matching? Відповідь визначає всю архітектуру.

Три моделі order book DEX

Повністю on-chain книга ордерів

Книга ордерів зберігається і матчиться прямо в смарт-контракті. Кожен ордер — транзакція. Кожен матч — транзакція.

Проблеми:

• Вартість газу: виставити ордер = транзакція. Відмінити = транзакція. Заповнити = транзакція.
• Затримка: блок Ethereum = ~12 секунд.
• Front-running: всі ордери видні в mempool

Застосовно лише для: аукціонів, системи batch settlement, низькочастотної торгівлі

Off-chain книга ордерів + on-chain розрахунок

Це домінуючий модель. Книга ордерів і matching — off-chain (швидко, бесплатно). Розрахунок фінального трейду — on-chain через смарт-контракт.

Приклади: dYdX v3 (Starkware), Injective Protocol, Serum (Solana)

Гібридний: off-chain ордери + on-chain matching

Ордери підписуються off-chain (EIP-712), зберігаються в off-chain orderbook, але matching виконується on-chain при розрахунку. Приклад: 0x Protocol, Hashflow.

Перевага: maker не платить газ за виставлення ордера — лише за виконання. Критично для market makers.

Смарт-контракти для розрахунку

EIP-712 підписи ордерів

Maker підписує ордер off-chain. Taker може заповнити цей ордер on-chain. Підпис верифікується через ecrecover.

Ключові аспекти безпеки:

• filledAmounts відслідковує частичні заповнення
• usedNonces запобігає replay атакам
• expiry обов'язковий
• transferFrom вимагає попереднього approve

Permit2 (Uniswap)

Проблема стандартного approve: користувач повинен відправити окрему approve транзакцію. Permit2 (UniswapLabs) вирішує це.

Це покращує UX для maker-ів: вони підписують ордер + permit однією EIP-712 підписю.

Off-chain matching engine

Архітектура

Matching engine для order book DEX — це високопроізводивний сервіс, подібний до CEX matching.

1. Ордери не зберігаються on-chain — вони існують як підписані сообщення
2. Частичне заповнення повинно відслідковуватися off-chain І on-chain
3. Скасування ордера = або on-chain nonce інвалідація, або off-chain "cancel"

Settlement батчинг

On-chain settlement дорогий. Стратегія: батчити матчи й відправляти кілька заповнень в одній транзакції.

Батч з 10 заповнень економить ~70% газу порівняно з 10 окремими транзакціями.

L2 і appchain підходи

Архітектура dYdX v4: Cosmos appchain

dYdX v4 перейшов зі Starkware L2 на власний Cosmos SDK appchain. Книга ордерів і matching — повністю off-chain на validators.

Переваги: нульові комісії для трейдерів (протокол платить з торгових комісій), <1ms matching latency, повна децентралізація matching.

Arbitrum / zkSync L2 підхід

Деплоймент на L2 зменшує газ в 10-100 разів. Для order book DEX це означає: on-chain розміщення ордера стає економічно доцільним для ордерів >$100.

Приклад: Lighter.xyz побудований на Arbitrum використовує повністю on-chain matching.

Starkware / zkProofs

dYdX v3 використовував StarkEx: matching off-chain, validity proofs відправлені on-chain.

Ліквідність: проблема холодного старту

Order book DEX без market makers = пустий стакан. Рішення:

Інтеграції з AMM: якщо немає market maker для якої-то пари — router автоматично виконує через AMM-пул.

Market maker програма: спеціальні умови для designated market makers.

RFQ (Request for Quote): замість публічної книги ордерів — запит котування напрямо до зареєстрованих market makers.

Порівняння з AMM

Для більшості DeFi-проектів AMM простіше запустити. Order book DEX варто будувати якщо: цільова аудиторія — професійні трейдери, потрібні limit ордери, або працюєте на L2/appchain з низькими комісіями.