Разработка мобильного приложения криптобиржи под ключ

Разработка мобильного приложения криптобиржи под ключ

Мы столкнулись с проектом, где клиент потерял 10% пользователей из-за лагов при обновлении цен в реальном времени на старых устройствах. Причина — неправильная архитектура WebSocket и рендеринг FlatList. Переписали на FlashList с дедупликацией подписок — задержка обновлений снизилась до 200 мс, uptime вырос до 99.9%. По данным CoinGecko, 78% трейдеров используют мобильные приложения для торговли. Мобильное приложение биржи — это не адаптированная веб-версия, а отдельный продукт с другим UX, требованиями к безопасности и техническими ограничениями. Пользователь с телефона торгует иначе: быстрые жесты, биометрия вместо пароля, меньше экрана. Наши инженеры имеют 5+ лет опыта в блокчейне и запустили 30+ проектов, поэтому знают типичные грабли. Разработка на React Native обходится на 37% дешевле нативных решений и сокращает время выхода на рынок в 2 раза. Экономия на эксплуатации достигает 40% за счёт OTA-обновлений.

Какие технические проблемы мы решаем

• Real-time обновления order book: 1000+ обновлений в секунду на слабых устройствах. Используем diff-патчи и прореживание (throttling) для уменьшения нагрузки на UI. Типичная ошибка — обновлять весь список при каждом сообщении, что приводит к артефактам и высокому потреблению CPU. Мы применяем useMemo и FlashList с константной высотой строк.
• Безопасность мобильного окружения: Токены в AsyncStorage — частая уязвимость. Используем SecureStore (iOS Keychain/Android Keystore) с биометрической защитой. Certificate pinning через react-native-ssl-pinning блокирует MITM-атаки. Jailbreak detection через jail-monkey предупреждает пользователя, но не блокирует полностью — чтобы не затронуть легитимные приложения.
• Push-уведомления с deep linking: После FCM/APNs пользователь должен попасть на экран ордера или вывода. Реализуем через React Navigation deep linking: exchange://trade/BTC-USDT открывает торговый экран напрямую. Очередь Redis + Bull гарантирует доставку без потерь.

Почему React Native оптимальный выбор для мобильной биржи?

React Native — основной выбор, если у вас уже есть веб-фронтенд на React. Переиспользуем бизнес-логику, одну кодовую базу на iOS и Android. Expo подходит для быстрого прототипирования; для продакшена мигрируем на bare workflow — так можно добавить кастомные нативные модули (secure enclave, биометрия). Flutter — альтернатива при отсутствии существующего JS кода: Dart обеспечивает высокую производительность, но библиотек для крипто меньше. Native (Swift/Kotlin) даёт максимум производительности, но две кодовые базы и большие расходы на поддержку — оправдано только для HFT-уровня.

В большинстве случаев React Native + Expo для старта, затем bare workflow — оптимальный баланс скорости разработки и производительности. Например, заказчик с веб-биржей на React смог запустить MVP за 10 недель вместо 16, сэкономив 37% бюджета за счёт переиспользования кода.

Архитектура приложения

State management

Стейт биржи сложный: реалтайм тикеры, order book, история сделок, балансы, активные ордера. Всё обновляется через WebSocket. Используем Zustand для локального стейта и React Query для серверного кэширования.

import { create } from 'zustand';
import { subscribeWithSelector } from 'zustand/middleware';

interface MarketStore {
  tickers: Record<string, Ticker>;
  orderBook: OrderBook | null;
  lastPrice: Record<string, string>;
  updateTicker: (pair: string, ticker: Ticker) => void;
  updateOrderBook: (book: OrderBook) => void;
}

const useMarketStore = create<MarketStore>()(
  subscribeWithSelector((set) => ({
    tickers: {},
    orderBook: null,
    lastPrice: {},
    updateTicker: (pair, ticker) =>
      set((state) => ({ tickers: { ...state.tickers, [pair]: ticker } })),
    updateOrderBook: (book) => set({ orderBook: book }),
  }))
);

WebSocket менеджер с автоматическим переподключением и дедупликацией подписок:

class WSManager {
  private ws: WebSocket | null = null;
  private subscriptions = new Set<string>();
  private reconnectTimer: NodeJS.Timeout | null = null;

  connect(url: string) {
    this.ws = new WebSocket(url);
    this.ws.onopen = () => {
      this.subscriptions.forEach(sub => this.ws!.send(sub));
    };
    this.ws.onclose = () => {
      this.reconnectTimer = setTimeout(() => this.connect(url), 3000);
    };
    this.ws.onmessage = (e) => this.handleMessage(JSON.parse(e.data));
  }
}

Навигация

React Navigation v6 — Auth Stack (Login, Register, 2FA) и Main Tabs (Home, Trade, Wallets, Orders, Profile). Deep linking для push-уведомлений.

Торговый экран

Самый сложный экран: TradingView chart через react-native-webview, order book через FlashList, форма ордера с калькулятором. Производительность — критична: используем useMemo и Reanimated для анимаций.

Как обеспечить безопасность приложения

Биометрическая аутентификация — обязательна. Используем expo-local-authentication и expo-secure-store для хранения JWT в iOS Keychain / Android Keystore.

import * as LocalAuthentication from 'expo-local-authentication';
import * as SecureStore from 'expo-secure-store';

async function authenticateWithBiometrics(): Promise<boolean> {
  const hasHardware = await LocalAuthentication.hasHardwareAsync();
  const isEnrolled = await LocalAuthentication.isEnrolledAsync();
  if (!hasHardware || !isEnrolled) return fallbackToPIN();
  const result = await LocalAuthentication.authenticateAsync({
    promptMessage: 'Подтвердите личность для выхода',
    disableDeviceFallback: false,
    cancelLabel: 'Отмена',
  });
  return result.success;
}

async function saveToken(token: string) {
  await SecureStore.setItemAsync('auth_token', token, {
    keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  });
}

Certificate pinning через react-native-ssl-pinning (пиннить промежуточный CA, не leaf). Jailbreak detection через jail-monkey (предупреждение).

Как оптимизировать производительность

• Hermes engine для быстрого старта и малого потребления памяти.
• expo-image для реимейджинга изображений.
• react-native-reanimated для анимаций на UI thread.
• Bundle splitting через Expo Router lazy loading.
• Сборка через EAS Build, OTA Updates для быстрых исправлений.
• CI/CD: GitHub Actions → EAS Build → TestFlight/Internal Testing → Production.

Типичная экономия: при переходе с нативных стеков на React Native стоимость разработки снижается на 30–40%, а время внедрения обновлений — на 60% за счёт OTA.

Процесс работы

1. Анализ требований и аудит существующей инфраструктуры (2–5 дней).
2. Прототипирование UX/UI с учётом мобильных жестов и биометрии (1–2 недели).
3. Разработка архитектуры WebSocket, state management, навигации (2–4 недели).
4. Интеграция API биржи и смарт-контрактов (2–3 недели).
5. Тестирование на 200+ сценариях и реальных устройствах (2–3 недели).
6. Деплой в App Store и Google Play + OTA-обновления (1–2 недели).
7. Пост-продакшн поддержка 3 месяца (исправление багов, мониторинг).

Закажите предварительную оценку на нашем сайте — это займёт 2 дня.

Сроки и бюджет

Бюджет проекта рассчитывается индивидуально в зависимости от сложности интеграций и требуемого набора фич. Обратитесь к нам — мы подготовим детальную оценку за 2 дня.

Что входит в результат

Свяжитесь с нами

Получите консультацию по вашему проекту. Мы проанализируем требования и предложим оптимальное решение. Закажите оценку через форму на сайте — это займёт 2 дня.

Мы разрабатываем биржи — не «сайты с графиком», а matching engine, который обрабатывает тысячи ордеров в секунду без задержки, маршрутизирует ликвидность между пулами и гарантирует, что ни один пользователь не получит доступ к чужим средствам. Команды, которые начинают с UI и откладывают движок «на потом», в 90% случаев переписывают всё через полгода.

Какие проблемы решает правильная архитектура?

Order Book vs AMM: где ломается большинство проектов

Централизованные биржи (CEX) строятся вокруг order book + matching engine. Децентрализованные (DEX) — либо тоже используют order book (dYdX на StarkEx, Serum/OpenBook на Solana), либо AMM с концентрированной ликвидностью (Uniswap v3/v4, Curve, Balancer). Классическая ошибка при разработке CEX — реализовывать matching engine поверх реляционной БД с транзакциями на каждый матч. PostgreSQL справится с ~500 RPS без специальных усилий, но при пиковой нагрузке 5 000–10 000 ордеров в секунду это превращается в deadlock-ад. Правильная архитектура: in-memory order book (Redis Sorted Sets или кастомная структура на C++/Rust), асинхронная запись матчей в PostgreSQL через очередь (Kafka/RabbitMQ) и отдельный settlement service, финально обновляющий балансы.

Для DEX самая болезненная проблема — sandwich атаки и MEV. Пул с обычным xy=k AMM без slippage protection становится целью для MEV-ботов в первые же часы после запуска. Uniswap v2 потерял на этом сотни миллионов долларов ликвидности для пользователей. Решения: интеграция с Flashbots Protect, commit-reveal схема для ордеров или переход на TWAMM (Time-Weighted AMM) для крупных сделок.

Концентрированная ликвидность и impermanent loss

Uniswap v3 ввёл концентрированную ликвидность — LP выбирают ценовой диапазон, в котором предоставляют ликвидность. Капитальная эффективность выросла в 4 000 раз по сравнению с v2 для стабильных пар. Но реализовать этот механизм правильно — нетривиальная задача. Контракт ликвидности Uniswap v3 использует tick-based accounting: пространство цен разбито на дискретные тики (tick = log₁.0001(price)), каждый тик хранит накопленные fee growth и liquidity delta. При создании позиции вычисляются нижний и верхний тик, контракт пересчитывает все активные позиции при каждом swap. Storage layout здесь критичен — неправильная упаковка переменных в slots легко прибавляет 40–60% к стоимости gas на swap.

Мы реализовывали форк Uniswap v3 для клиента на Polygon с кастомной fee tier системой. Первоначальная версия тратила 180k gas на swap через 2 тика. После slot packing переменных в Tick.Info и инлайнинга нескольких internal вызовов — 112k gas. Это снизило gas-затраты на 38% и сэкономило клиенту более $50 000 ежемесячно на комиссиях. Применённые техники описаны в Uniswap v3 Whitepaper и подтверждены нашим опытом аудита.

Что такое matching engine и почему он критичен?

Production-ready matching engine строится по следующей схеме:

• Order ingestion layer — WebSocket gateway (Go или Rust), принимает ордера, валидирует подпись, проверяет баланс через Redis, ставит в очередь. Latency на этом уровне должна быть <1ms.
• Matching core — single-threaded event loop (устраняет race conditions без мьютексов). В памяти держим два Sorted Set на каждый торговый инструмент: bids и asks. FIFO matching для limit ордеров, immediate-or-cancel для маркет. Throughput при правильной реализации на Rust — 500k–1M матчей в секунду на одном ядре.
• Settlement service — читает матчи из Kafka, атомарно обновляет балансы в PostgreSQL (UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1). Optimistic locking через версионирование строк.
• Withdrawal pipeline — отдельный сервис с cold/hot wallet архитектурой. Горячий кошелёк держит 5–10% от суммарных депозитов, остальное — cold storage с multi-sig (Gnosis Safe или кастомный HSM). Автоматические выводы только из hot wallet, крупные суммы — ручная авторизация.

Как мы строим on-chain DEX: смарт-контракты и gas-оптимизация

Для DEX на EVM (Ethereum, Arbitrum, Optimism, Polygon) весь критический путь живёт в Solidity. Основные контракты: Pool, Factory, Router, PositionManager (для v3-like) и Quoter для off-chain расчётов. Типичные ошибки, которые мы видим в аудитах:

Reentrancy через callback. Uniswap v3 использует flash swap с callback (uniswapV3SwapCallback). Если в вашем роутере нет nonReentrant guard и вы не проверяете msg.sender == pool, контракт дренируется через вложенный вызов. Это не гипотетика — несколько форков v3 теряли средства именно так.

Oracle manipulation в AMM. Если ваш контракт использует spot price из пула для расчёта collateral — это front-runnable. Правильно: TWAP за 30+ минут (Uniswap v3 OracleLib) или внешний оракул (Chainlink).

Unbounded loops в liquidity range. Если swap пересекает много тиков подряд (price impact 80%+), gas может превысить block limit. Нужен MAX_TICKS_CROSSED с partial fill и возвратом остатка.

Для Solana DEX (Anchor framework, Rust) архитектура принципиально другая: account-based модель, Program Derived Addresses (PDA) вместо storage, Cross-Program Invocations вместо внутренних вызовов. Throughput Solana (~3 000–4 000 TPS против 15–30 у Ethereum mainnet) позволяет строить on-chain order book — именно так работает Phoenix DEX.

Liquidity bootstrapping и интеграция с агрегаторами

Запустить пул мало — нужно обеспечить ликвидность на старте. Практические механизмы:

• Liquidity Bootstrapping Pool (LBP) — начальная цена высокая, весовые коэффициенты активов динамически смещаются, создавая давление продаж и равномерное распределение токена. Реализован в Balancer v2.
• Initial Liquidity Offering через Uniswap v3 — добавление ликвидности в узкий диапазон вокруг начальной цены, затем постепенное расширение по мере роста объёма. Требует active liquidity management или интеграции с Arrakis/Gamma.
• Интеграция с 1inch, Paraswap, Li.Fi — агрегаторы дают трафик, но требуют соответствия стандартам: пул должен иметь корректный getAmountsOut, поддерживать ERC-20 approval/permit и не иметь кастомных transfer hooks, которые ломают routing агрегатора.

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

Аналитика и проектирование начинаются с выбора архитектурной модели: CEX с кастодиальным хранением, non-custodial DEX или гибрид (off-chain order book + on-chain settlement, как dYdX v3). Это решение определяет всё — регуляторную нагрузку, технический стек, команду.

Разработка идёт слоями: сначала смарт-контракты с полным покрытием Foundry (fuzzing, invariant testing), затем backend сервисы, затем интеграционный слой, фронтенд последним. Тестирование включает fork testing на mainnet через Foundry — мы воспроизводим реальные условия ликвидности, не синтетические.

Аудит обязателен перед деплоем на mainnet. Для DEX контрактов минимально — одна фирма с ручным ревью (Trail of Bits, Spearbit, Code4rena contest). Для CEX custody — аудит процессов хранения ключей. Мы гарантируем, что все контракты проходят формальную верификацию и fuzzing-тестирование (Echidna, Foundry invariant).

Что входит в работу (deliverables)

По завершении проекта вы получаете:

• Исходный код смарт-контрактов и backend-сервисов под вашу лицензию
• Полную техническую документацию (архитектурные схемы, API-спецификации, инструкции по деплою)
• Доступы к репозиторию и CI/CD pipeline
• Обучение вашей команды работе с кодом (2–3 сессии)
• Гарантию на найденные в процессе эксплуатации баги до 6 месяцев
• Сертификат прохождения стороннего аудита безопасности

Ориентиры по срокам

• DEX (AMM, xy=k) — от 3 до 5 месяцев: контракты + backend + UI
• DEX с концентрированной ликвидностью (v3-like) — от 6 до 10 месяцев
• CEX (matching engine + custody + торговый UI) — от 8 до 14 месяцев
• Интеграция с существующим протоколом — от 4 до 8 недель

Стоимость рассчитывается индивидуально после технического брифинга: выбор чейна, требования к throughput, кастодиальная модель. Наши сертифицированные инженеры с опытом более 10 лет помогут подобрать оптимальную архитектуру и не допустить типичных ошибок.

Типичные грабли при запуске

• Забывают про price oracle в AMM. Spot price манипулируется flash loan’ом за одну транзакцию. Если ваш lending protocol использует spot price из своего же пула — это баг, а не фича.
• Горячий кошелёк без лимитов. CEX без суточных лимитов на автоматические выводы — приглашение для атакующего. Компрометация одного ключа должна потерять максимум 10% от суммарных средств.
• Отсутствие circuit breaker. Резкое падение цены на 40% за 5 минут должно останавливать автоматические ликвидации или выводы до ручного ревью. Без этого cascading liquidation spiral уничтожает весь TVL.
• Неправильный decimal handling. USDC использует 6 decimals, WBTC — 8, большинство токенов — 18. Смешивание без нормализации даёт либо потерю точности, либо overflow. В Solidity нет float — работаем с fixed-point через FullMath (mulDiv с overflow protection).

Хотите избежать этих проблем? Свяжитесь с нами для консультации — мы подберём архитектуру под ваш проект и назовём точные сроки. Закажите разработку биржи с гарантией качества и последующей поддержкой.