Разработка централизованной криптобиржи (CEX) — один из самых сложных продуктов в криптоинфраструктуре. Matching engine, кастодиальная система, compliance-слой, market data и обеспечение ликвидности — всё это должно работать одновременно, надёжно и под нагрузкой. Типичные проблемы: latency матчинга более 100 мс, уязвимости в смарт-контрактах, низкая доступность. Мы проектируем и разрабатываем CEX под ключ, опираясь на 8-летний опыт в блокчейн-разработке и 5+ запущенных проектах. Ниже расскажу, что реально нужно для запуска серьёзной платформы.
Как мы проектируем архитектуру CEX?
Высокоуровневая схема
Client Layer ├── Web Trading Terminal (React/Vue) ├── Mobile Apps (iOS/Android) └── API (REST + WebSocket + FIX) │ API Gateway / Load Balancer │ Service Layer ├── Auth Service (JWT + 2FA) ├── Order Service → OMS ├── Account Service → Balances ├── Market Data Service → Feeds └── Notification Service │ Core Infrastructure ├── Matching Engine (C++/Rust/Go) ├── Risk Engine ├── Custody System └── Settlement Engine │ Data Layer ├── PostgreSQL (accounts, orders, trades) ├── Redis (order book state, sessions) ├── Kafka (event streaming, audit log) └── TimescaleDB (OHLCV, market data) Принцип изоляции сервисов
Каждый сервис независим и общается через события (event-driven). Matching engine не знает про пользователей — он знает только про ордера. Account service не знает про торговлю — он знает про балансы. Это позволяет независимо масштабировать компоненты: matching engine на bare metal, остальное на Kubernetes. Сбой notification service не роняет торговлю. Деплой без downtime.
Почему matching engine так критичен?
Matching engine — единственный компонент, где производительность имеет экзистенциальное значение. Задержка >10 ms — это реальные потери для HFT-клиентов и market makers.
| Tier | Throughput | Latency (order-to-ack) | Технология |
|---|---|---|---|
| Start-up (<$1M/day) | 1,000 ops/sec | <50 ms | Go / Java |
| Mid-tier ($1-50M/day) | 10,000 ops/sec | <5 ms | Go / Rust |
| Large ($50M+/day) | 100,000+ ops/sec | <500 µs | C++ / Rust |
Order Book имплементация
use std::collections::BTreeMap; use std::collections::VecDeque; type Price = u64; // Integer representation: price * 10^8 type Quantity = u64; #[derive(Debug, Clone)] struct Order { id: u64, price: Price, quantity: Quantity, remaining: Quantity, side: Side, order_type: OrderType, timestamp: u64, user_id: u64, } #[derive(Debug)] struct PriceLevel { price: Price, total_quantity: Quantity, orders: VecDeque<u64>, // order IDs в порядке времени } struct OrderBook { symbol: String, bids: BTreeMap<std::cmp::Reverse<Price>, PriceLevel>, asks: BTreeMap<Price, PriceLevel>, orders: std::collections::HashMap<u64, Order>, } impl OrderBook { fn match_order(&mut self, incoming: &mut Order) -> Vec<Trade> { let mut trades = Vec::new(); let opposite_side = match incoming.side { Side::Buy => &mut self.asks, Side::Sell => &mut self.bids, }; while incoming.remaining > 0 { let best_level = match incoming.side { Side::Buy => opposite_side.iter_mut().next(), Side::Sell => opposite_side.iter_mut().next(), }; match best_level { None => break, Some((_, level)) => { let price_matches = match incoming.side { Side::Buy => incoming.price >= level.price, Side::Sell => incoming.price <= level.price, }; if !price_matches { break; } while incoming.remaining > 0 && !level.orders.is_empty() { let maker_id = *level.orders.front().unwrap(); let maker = self.orders.get_mut(&maker_id).unwrap(); let fill_qty = incoming.remaining.min(maker.remaining); trades.push(Trade { maker_order_id: maker_id, taker_order_id: incoming.id, price: level.price, quantity: fill_qty, }); incoming.remaining -= fill_qty; maker.remaining -= fill_qty; if maker.remaining == 0 { level.orders.pop_front(); self.orders.remove(&maker_id); } } } } } trades } } Matching engine на Rust обрабатывает в 3 раза больше операций, чем аналогичный на Python. Мы используем Event Sourcing — все изменения состояния записываются как неизменяемая последовательность событий (OrderPlaced → OrderMatched → TradeFilled → OrderCancelled). Это даёт полный audit trail и возможность восстановления после краха, что признано лучшей практикой в высоконагруженных системах. Для mid-tier биржи экономия на инфраструктуре за счёт правильной архитектуры может быть значительной. Дополнительно, для проектов с объёмом торгов $1M/day мы снижаем затраты на KYC-интеграцию.
Как обеспечивается безопасность кастодиальной системы
Биржа хранит средства пользователей. Мы реализуем многоуровневую защиту:
- Multi-sig cold storage: 95%+ средств в холодных кошельках с 3-of-5 multisig. Ключи физически разнесены по разным дата-центрам и странам. Используем HSM (Hardware Security Modules) для подписания.
- Hot wallet: 2-5% средств для оперативных выводов с автоматическим пополнением из cold. Суточный лимит вывода превышает который требует ручного одобрения.
- Withdrawal security: каждый вывод проверяется на whitelist адресов, velocity, AML-скрининг (Chainalysis, Elliptic). Сомнительные транзакции уходят на manual review.
Детали реализации кастодиальной защиты
Для подписания транзакций используем HSM с ключами, разделёнными по принципу sharded secret. Каждая транзакция требует подтверждения от 3 из 5 ключей. Данные о балансах хранятся в отдельной базе с шифрованием на уровне строк.KYC/AML и compliance
Таблица уровней верификации:
| KYC Level | Данные | Дневной лимит |
|---|---|---|
| 0 — Email | Только email | 0 (только просмотр) |
| 1 — Basic | Телефон + страна | $500 |
| 2 — Standard | ID + Selfie | $10,000 |
| 3 — Enhanced | Proof of address + source of funds | $100,000 |
| Institutional | Корпоративные документы | Unlimited |
Интегрируем Sumsub или Onfido через REST API. Webhook при изменении статуса верификации. AML-скрининг каждого депозита и вывода в реальном времени.
Рыночные данные и интеграция TradingView
Real-time feeds
Matching Engine → Trade Events → Kafka │ ┌──────────┤ ▼ ▼ OHLCV Builder Order Book Aggregator │ │ └────┬─────┘ ▼ WebSocket Broadcaster (horizontal scaling) │ ┌─────────┼─────────┐ ▼ ▼ ▼ Client 1 Client 2 Client N WebSocket сервер публикует diff updates (дельта-изменения), что снижает трафик в 10-50 раз. Для профессионального trading terminal интегрируем TradingView Advanced Charts через UDF data feed и WebSocket.
Процесс работы над проектом
- Аналитика: исследование рынка, требования, выбор стека, экономика проекта.
- Проектирование: архитектура, прототип matching engine, спецификация API.
- Реализация: разработка всех модулей, написание смарт-контрактов (если нужны) на Solidity или Rust.
- Тестирование: unit, integration, load testing (до 50k ops/sec). Безопасность — аудит смарт-контрактов и pen test.
- Деплой: настройка инфраструктуры, мониторинг, запуск в продакшн. Обеспечение ликвидности через ботов или market makers.
Что входит в работу
- Документация (архитектурная, API, deployment)
- Исходный код с тестами
- CI/CD pipeline
- Доступы к инфраструктуре
- Обучение команды
- Поддержка 3 месяца после запуска
Сроки: от 12 до 24 месяцев в зависимости от функционала. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта. Мы подготовим детальную смету и roadmap. Типичный проект обходится заказчику в диапазоне, который мы обсуждаем индивидуально — но экономия на инфраструктуре за счёт правильной архитектуры может достигать 40% по сравнению с типовыми решениями. Мы разработали уже 5+ бирж и знаем все подводные камни. Получите консультацию по вашему проекту — оценим и предложим оптимальное решение.