Розробка централізованої криптобіржі (CEX) — один із найскладніших продуктів у криптоінфраструктурі. Це справжня високонавантажена біржа, яка потребує matching engine (торговий двигун), кастодіальної системи, compliance-шару, market data та забезпечення ліквідності біржі — все це має працювати одночасно, надійно та під навантаженням. Типові проблеми: latency матчингу понад 100 мс, вразливості в смарт-контрактах, низька доступність. Ми проектуємо та розробляємо криптобіржу під ключ, спираючись на 8-річний досвід у блокчейн розробці та 5+ запущених проєктів. Ми гарантуємо якість та безпеку, а наші сертифіковані фахівці забезпечують надійність. Нижче розповім, що реально потрібно для запуску серйозної платформи.
Як ми проектуємо архітектуру криптобіржі?
Високорівнева схема
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 біржі економія на інфраструктурі за рахунок правильної архітектури може бути значною. Для прикладу, типовий проект CEX-біржі обходиться в $200,000–$500,000, а правильна архітектура дозволяє заощадити до 40% на інфраструктурі.
Як забезпечується безпека криптобіржі?
Біржа зберігає кошти користувачів. Ми реалізуємо багаторівневий захист:
- 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-скринінг кожного депозиту та виведення в реальному часі. Ми будуємо KYC 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+ бірж і знаємо всі підводні камені. Отримайте консультацію щодо вашого проекту — оцінимо та запропонуємо оптимальне рішення.