Розробка order book DEX: смарт-контракти та архітектура

Трейдери звикли до лімітних ордерів і стаканів на CEX. Але на DeFi-біржах з AMM це недоступно — тільки market order з прослизанням. Ми будуємо order book децентралізовану біржу (order book DEX), який дає ліквідність CEX без відмови від децентралізації. Наша команда має 10+ років досвіду та сертифікати аудиту смарт-контрактів (гарантія безпеки). Проблеми, які ми вирішуємо: газові витрати on-chain зберігання (кожен ордер — транзакція, кожен матч — транзакція; при частоті торгівлі це економічно недоцільно — рішення: off-chain matching engine + on-chain settlement), front-running і MEV (у публічному мемпулі ордери видно всім; боти можуть випередити вашу транзакцію — використовуємо EIP-712 підписи з нестандартними nonce, інтеграцію з Flashbots і батчинг транзакцій), ліквідність на старті (порожній стакан відлякує трейдерів — рішення: інтеграція з AMM-пулами як fallback, RFQ-сервіс для institutional ордерів, програма market maker зі зниженими комісіями).

Яку модель order book обрати?

Fully on-chain order book: order book зберігається і матчиться прямо в смарт-контракті. Кожен ордер — транзакція. Вартість газу висока: виставити, скасувати, заповнити — все платить трейдер. Latency ~12 секунд (блок Ethereum). Front-running неминучий. Підходить тільки для аукціонів і batch settlement.

Off-chain order book + on-chain settlement: домінуюча модель. Matching — off-chain (швидко, безкоштовно). Тільки фінальний трейд фіксується on-chain. Приклади: dYdX v3 (Starkware), Serum (Solana). Off-chain matching краще повністю on-chain у 10-100 разів за вартістю газу та в 10 разів за швидкістю.

Hybrid: off-chain orders + on-chain matching: ордери підписуються off-chain (EIP-712), зберігаються в off-chain order book, але matching виконується on-chain при settlement. Приклад: 0x Protocol, Hashflow. Maker не платить газ за виставлення — тільки за виконання.

Смарт-контракти для settlement

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

// SPDX-License-Identifier: MIT pragma solidity ^0.8.19; contract OrderBookSettlement { bytes32 public constant ORDER_TYPEHASH = keccak256( "Order(address maker,address taker,address makerToken,address takerToken," "uint256 makerAmount,uint256 takerAmount,uint256 nonce,uint256 expiry)" ); struct Order { address maker; address taker; // address(0) = any taker address makerToken; address takerToken; uint256 makerAmount; uint256 takerAmount; uint256 nonce; uint256 expiry; } mapping(address => mapping(uint256 => bool)) public usedNonces; mapping(bytes32 => uint256) public filledAmounts; // partial fills function fillOrder( Order calldata order, bytes calldata signature, uint256 takerFillAmount // for partial fills ) external { require(block.timestamp < order.expiry, "ORDER_EXPIRED"); require( order.taker == address(0) || order.taker == msg.sender, "INVALID_TAKER" ); bytes32 orderHash = getOrderHash(order); require( filledAmounts[orderHash] + takerFillAmount <= order.takerAmount, "OVERFILL" ); // Verify EIP-712 signature address recovered = recoverSigner(orderHash, signature); require(recovered == order.maker, "INVALID_SIGNATURE"); // Calculate maker amount proportional to partial fill uint256 makerFillAmount = (order.makerAmount * takerFillAmount) / order.takerAmount; filledAmounts[orderHash] += takerFillAmount; // Atomic swap IERC20(order.takerToken).transferFrom(msg.sender, order.maker, takerFillAmount); IERC20(order.makerToken).transferFrom(order.maker, msg.sender, makerFillAmount); emit OrderFilled(orderHash, order.maker, msg.sender, makerFillAmount, takerFillAmount); } } 

Специфікація EIP-712: Ethereum typed structured data визначає структуру підпису. Ключові security-аспекти: filledAmounts для часткового заповнення, usedNonces проти replay, обов'язковий expiry. Для стандартного approve потрібна окрема транзакція — Permit2 від Uniswap Labs вирішує це одним підписом.

Як працює off-chain matching engine?

Це високопродуктивний сервіс, схожий на CEX matching, але з особливостями:

1. Ордери — підписані повідомлення, не on-chain.
2. Часткове заповнення відстежується off-chain і on-chain (mapping filledAmounts).
3. Скасування ордера: on-chain nonce або off-chain cancel з підтвердженням maker-а.

from dataclasses import dataclass from decimal import Decimal from typing import Optional import asyncio @dataclass class SignedOrder: maker: str taker_token: str maker_token: str taker_amount: Decimal maker_amount: Decimal nonce: int expiry: int signature: str @property def price(self) -> Decimal: """Ціна в одиницях maker_token за taker_token""" return self.maker_amount / self.taker_amount @property def is_expired(self) -> bool: import time return time.time() > self.expiry class OffChainOrderBook: def __init__(self, pair: str): self.pair = pair self.bids: list[SignedOrder] = [] # buy orders, sorted by price DESC self.asks: list[SignedOrder] = [] # sell orders, sorted by price ASC self._settlement_queue = asyncio.Queue() async def add_order(self, order: SignedOrder, side: str): if side == 'bid': self.bids.append(order) self.bids.sort(key=lambda x: x.price, reverse=True) else: self.asks.append(order) self.asks.sort(key=lambda x: x.price) await self.try_match() async def try_match(self): while self.bids and self.asks: best_bid = self.bids[0] best_ask = self.asks[0] if best_bid.is_expired: self.bids.pop(0) continue if best_ask.is_expired: self.asks.pop(0) continue if best_bid.price >= best_ask.price: # Match found fill_amount = min(best_bid.taker_amount, best_ask.taker_amount) await self._settlement_queue.put({ 'bid': best_bid, 'ask': best_ask, 'fill_amount': fill_amount }) # Update or remove filled orders best_bid.taker_amount -= fill_amount best_ask.taker_amount -= fill_amount if best_bid.taker_amount == 0: self.bids.pop(0) if best_ask.taker_amount == 0: self.asks.pop(0) else: break 

Скільки економить батчинг?

Батч із 10 заповнень в одній транзакції економить ~70% газу порівняно з 10 окремими — це в 3 рази вигідніше. Перехід на L2 може знизити операційні витрати в 10-100 разів. Вартість розгортання смарт-контракту в Ethereum — $500-2000.

function fillOrderBatch( Order[] calldata orders, bytes[] calldata signatures, uint256[] calldata fillAmounts ) external { require(orders.length == signatures.length, "LENGTH_MISMATCH"); for (uint256 i = 0; i < orders.length; i++) { fillOrder(orders[i], signatures[i], fillAmounts[i]); } } 

Що дають L2 і appchain?

Розгорнути: dYdX v4 на Cosmos appchain дає нульові fees для трейдерів і <1ms latency. Arbitrum / zkSync L2 знижують вартість газу в 10-100 разів — on-chain ордери стають економічними при об'ємах >$100. Starkware з validity proofs масштабує до 10,000+ trades/sec. Використання zk-Rollup з validity proofs дозволяє досягти затримки <1 сек та пропускної здатності 1000+ TPS. Для запобігання reorg атак використовується фінальність блокчейну.

Як забезпечити ліквідність на старті?

Інтеграція з AMM: якщо немає market maker — router направляє в AMM-пул (наприклад, Uniswap V3). Market maker програма: знижені fees, кредитна лінія, пріоритет matching. RFQ: institutional трейдери запитують котирування безпосередньо у зареєстрованих MM.

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

Процес розробки

1. Аналітика: вибір блокчейну, L2, моделі matching (on-chain/off-chain/hybrid).
2. Проектування: архітектура смарт-контрактів, off-chain сервісів, API.
3. Реалізація: розробка settlement контрактів, matching engine, інтеграція гаманців.
4. Тестування: unit-тести, інтеграційні тести, фаззинг (Echidna), симуляція на testnet.
5. Аудит: автоматичний (Slither, Mythril) і ручний код-рев'ю — гарантія безпеки.
6. Деплой: послідовний rollout з моніторингом.

Що входить в роботу

Документація архітектури та API, доступ до вихідного коду контрактів і matching engine, інструкції з розгортання та моніторингу, навчання команди адмініструванню, підтримка протягом місяця після деплою. Часті питання про вибір моделі, захист, строки розробки та вартість вказані окремо.

Строки: MVP за 2–3 місяці, повноцінна система з L2 і RFQ — від 6 місяців. Вартість MVP починається від $30,000, повноцінної системи — від $100,000. Для оцінки вашого проєкту звертайтеся — надамо кошторис за 2 дні.