Разработка мобильного криптокошелька (кастодиальный)
В кастодиальном кошельке приватные ключи пользователей хранятся на стороне оператора. Это фундаментальное отличие от некастодиального: пользователь доверяет оператору управление своими активами, оператор берёт на себя ответственность за безопасность. Именно такую модель используют большинство централизованных бирж (Coinbase, Binance) и корпоративных крипто-решений.
Технически проще для пользователя — не нужно беречь seed-фразу, есть привычное восстановление через email. Но требования к безопасности серверной инфраструктуры и регуляторная нагрузка — несравнимо выше.
Архитектура хранения ключей
Хранить приватные ключи пользователей в обычной базе данных — это приговор при первом же взломе. Правильная архитектура:
HSM (Hardware Security Module). Физическое устройство, которое генерирует, хранит и использует ключи — они никогда не выходят за пределы HSM. Подписание транзакций происходит внутри HSM: приложение отправляет транзакцию, HSM возвращает подписанную транзакцию, ключ не экспортируется. Популярные решения: Thales Luna, AWS CloudHSM, Azure Dedicated HSM.
KMS (Key Management Service). Облачный аналог: AWS KMS, Google Cloud KMS, Azure Key Vault. Ключи не экспортируются, операции подписания через API. Дешевле HSM, проще в масштабировании, но ключи в облаке провайдера — регуляторные ограничения для некоторых юрисдикций.
MPC (Multi-Party Computation). Современный подход: приватный ключ никогда не существует целиком в одном месте. Несколько участников (серверные узлы) имеют шарды ключа, подписание происходит через MPC-протокол без реконструкции ключа. Fireblocks, Fordefi, ZenGo используют этот подход. Устойчиво к компрометации одного узла.
Схема холодного/горячего хранения. Большинство средств — в холодном хранилище (offline HSM, hardware wallets). Горячий кошелёк (online) — только операционный запас для обработки текущих выводов. Соотношение 95/5 или 98/2 — отраслевой стандарт для бирж.
Серверная архитектура транзакций
Клиентское приложение не подписывает транзакции — оно только инициирует запрос. Флоу:
- Пользователь вводит параметры вывода в мобильном приложении
- Приложение отправляет запрос на бэкенд с аутентификацией (JWT + 2FA)
- Бэкенд валидирует: достаточно ли средств, не превышены ли лимиты, не в whitelist ли адрес
- Запрос ставится в очередь на подписание (не автоматически — может быть ручная или автоматическая апробация)
- Signing service запрашивает HSM/KMS подписать транзакцию
- Подписанная транзакция уходит в блокчейн-узел
- Мониторинг подтверждений, уведомление пользователя
Очередь транзакций — не просто async processing. Это защита от параллельных атак: два запроса на вывод одного баланса не должны оба пройти. Оптимистичная блокировка или pessimistic lock на уровне аккаунта при инициации вывода.
Аккаунтинг: UTXO vs account-based
Для Ethereum-совместимых сетей — account-based модель. Один адрес на пользователя или адрес-пул с account mapping:
- Dedicated address: каждый пользователь получает уникальный депозитный адрес → проще идентификация входящих, дороже в gas при консолидации
- Shared address + memo/tag: один депозитный адрес, идентификация через memo (как XRP, TON) или calldata
Для Bitcoin — UTXO. Каждый UTXO принадлежит конкретному пользователю или требует address-transaction mapping. Конкретный Bitcoin адрес для каждого депозита, sweep UTXO на холодный кошелёк по расписанию.
Внутренняя база аккаунтинга должна давать мгновенные балансы без блокчейн-запроса. Все операции — в внутренней БД, блокчейн — финальное подтверждение. Это как в банке: внутренняя бухгалтерская система не ждёт Fedwire для каждого запроса баланса.
Мобильный клиент: особенности кастодиальной модели
Для пользователя кастодиальный кошелёк ближе к банковскому приложению, чем к MetaMask. Функционал:
- Регистрация/логин с KYC (если требуется регулятором)
- Балансы по активам в реальном времени (WebSocket для live updates)
- История транзакций с фильтрами
- Отправка (с адресной книгой, QR-сканером, whitelist адресов)
- Получение (QR с адресом, мониторинг входящих)
- Swap между активами (через внутренний движок или агрегатор)
Биометрическая аутентификация на устройстве — для подтверждения операций, но сам ключ она не защищает (ключи на сервере). Здесь биометрия защищает сессию приложения.
KYC и AML — регуляторная обязанность
Кастодиальный кошелёк в большинстве юрисдикций — финансовый сервис. VASP (Virtual Asset Service Provider) по FATF Recommendations. Это означает:
- KYC (Know Your Customer): верификация личности, документы, selfie liveness check. Интеграция с провайдерами: Sumsub, Onfido, Jumio, Veriff
- AML screening: проверка транзакций против санкционных списков (OFAC, EU), блокировка известных миксеров и darknet адресов. Провайдеры: Chainalysis, Elliptic, TRM Labs
- Travel Rule (FATF Recommendation 16): при переводах > $1000 нужно передавать данные отправителя/получателя между VASP. Протоколы: TRP, OpenVASP, TRISA
Без этого в ЕС, США, большинстве развитых стран — нельзя законно работать. Интеграция KYC/AML — обязательный этап, не опциональный.
Push-уведомления и мониторинг
Мониторинг входящих транзакций — через webhook от блокчейн-провайдера (Alchemy Webhooks, Moralis Streams, QuickNode Streams) или собственный event listener. При подтверждении депозита — зачислить на внутренний баланс, отправить push через FCM/APNs.
Уведомления о подозрительной активности: вход с нового устройства, вывод крупной суммы, смена email — немедленный push + email.
Сроки и этапы
MVP кастодиального кошелька (один блокчейн, базовые операции, KMS вместо HSM, упрощённый KYC) — 2–3 месяца. Полноценная система с HSM/MPC, мультичейн поддержкой, AML интеграцией, регуляторной отчётностью — 6–12 месяцев командой. Регуляторная часть (получение лицензии VASP) — параллельный процесс, сроки зависят от юрисдикции. Стоимость рассчитывается после анализа требований: количество блокчейнов, юрисдикции, объём KYC/AML, требования к инфраструктуре безопасности.