Разработка централизованной криптобиржи (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+ бирж и знаем все подводные камни. Получите консультацию по вашему проекту — оценим и предложим оптимальное решение.