MPC-кошелёк: разработка с распределённым управлением ключами

Разработка MPC-кошелька

Мы разрабатываем MPC-кошельки для распределённого управления ключами без единой точки отказа. Традиционный криптокошелёк держит приватный ключ в одном месте: на устройстве, в HSM, в облаке. Любое компрометирование этого места = потеря средств. Multi-Party Computation решает фундаментальную проблему по-другому: приватный ключ никогда не существует целиком ни в одной точке системы. Вместо этого несколько сторон держат key shares и совместно вычисляют подпись, не раскрывая друг другу своих долей.

Это не мультисиг. В мультисиге подпись транзакции требует M из N подписей, каждая из которых видна on-chain — сеть знает, что используется мультисиг. В MPC финальная подпись выглядит как обычная ECDSA подпись одного ключа. Никакого on-chain overhead, никаких изменений в протоколе. Это критично для: снижения gas costs (на 30% по сравнению с мультисигом), privacy (скрывает схему управления ключами), совместимости с любыми chain и dApp. За 5 лет работы на рынке блокчейн-разработки мы реализовали 30+ проектов, включая MPC-кошельки для ведущих DeFi-протоколов.

Как устроена математика MPC-кошелька?

Shamir's Secret Sharing и threshold schemes

Основа MPC-кошельков — threshold signature schemes (TSS). Наиболее используемые: GG18, GG20 (Gennaro-Goldfeder), CGGMP (Canetti-Gennaro-Goldfeder-Makriyannis-Peled), и DKLS.

Shamir's Secret Sharing — базовое понятие, но не сама TSS. В SSS секрет делится на N шардов, M из N достаточно для восстановления. Проблема: восстановление требует собрать шарды в одном месте — уязвимость. TSS устраняет это: подпись вычисляется без сборки ключа.

Threshold ECDSA (используем secp256k1 как в Bitcoin/Ethereum):

Пусть приватный ключ d = d1 + d2 (mod q) для 2-of-2 схемы. Каждая сторона держит d1 и d2. При подписи:

1. Каждая сторона генерирует свой nonce: k1, k2
2. Совместно вычисляют R = (k1 + k2)^(-1) * G (commitment protocol)
3. Каждая сторона вычисляет свою часть s: s1, s2
4. Финальная подпись: s = s1 + s2 (mod q) 
5. Подпись (r, s) — обычная ECDSA подпись

Сложность в шаге 2: прямое вычисление потребует раскрытия k1 или k2. Поэтому используется Oblivious Transfer, Paillier encryption или Curve25519-based протоколы для безопасного вычисления.

Протоколы: GG20 vs CGGMP

GG20 (Gennaro-Goldfeder) — долгое время стандарт де-факто. Используется в Fireblocks, ZenGo, Coinbase Wallet. Поддерживает threshold t-of-n для произвольных t и n. Требует Paillier encryption для secure multiplication. Недостатки GG20: сложность реализации, дорогой keygen (O(n²) коммуникаций), уязвимость к rouge key attack требует range proofs что увеличивает размер сообщений.

CGGMP (Canetti-Gennaro-Goldfeder-Makriyannis-Peled) — текущий state-of-the-art. Исправляет уязвимости GG20, более эффективный signing (меньше раундов коммуникации). Поддерживает identifiable abort — если одна сторона ведёт себя злонамеренно, можно идентифицировать её по криптографическому доказательству.

DKLS — альтернатива на основе Oblivious Transfer. Более компактные сообщения, но меньше реализаций в production.

Key refresh

Критически важная операция: периодическое обновление key shares без изменения публичного ключа (а значит, без смены адреса). Если атакующий скомпрометировал один шард, но не успел получить финальную подпись до refresh — компрометация нейтрализована.

Refresh protocol (упрощённо):
1. Каждая сторона генерирует новые random shares: r1, r2, ...rn
2. Суммируют: Σri = 0 (нулевое суммарное изменение)
3. Каждая сторона добавляет свой ri к текущему di
4. Публичный ключ d*G не меняется: Σ(di + ri)*G = d*G + Σri*G = d*G

Рекомендуемая частота refresh: каждые 30-90 дней, или при подозрении на компрометацию любого участника.

Как построена архитектура production MPC-кошелька?

Типичная 2-of-3 схема для мобильного кошелька

┌──────────────────────────────────────────────────────┐
│  User Device (Mobile)   │  Company Server  │  Backup  │
│  Share 1 (локально,     │  Share 2         │  Share 3 │
│  зашифрован биометрией) │  (HSM/TEE)       │  (MPC    │
│                         │                  │  backup) │
└──────────────────────────────────────────────────────┘

Signing: Device + Server (2-of-3)
Recovery: Device + Backup или Server + Backup

Пользователь теряет телефон → восстановление через Server + Backup шарды. Сервер взломан → нет шанса без Device или Backup. Это модель ZenGo и аналогичных non-custodial MPC кошельков.

Компоненты системы

• Key generation service. Реализует DKG (Distributed Key Generation) протокол между участниками. Результат: каждый участник получает свой share, никто не знает полный ключ. Реализации: tss-lib (Binance, Go), multi-party-ecdsa (ZenGo, Rust), threshold-sig-lib (Fireblocks internal).

// ZenGo's curv + tss-lib пример (Rust)
use curv::elliptic::curves::{Secp256k1, Point, Scalar};
use multi_party_ecdsa::protocols::multi_party_ecdsa::gg_2020::party_i::*;

// Phase 1: каждая сторона генерирует commitment
let party1_keys = Keys::create(1);
let (commit1, decom1) = party1_keys.phase1_broadcast_phase3_proof_of_correct_key();

// Phase 2: обмен commitments, вычисление vss
// Phase 3-5: verification и финализация shares
// Результат: party1_keys.u_i — приватный share стороны 1

• Signing service. Оркестрирует signing sessions между участниками. Должен поддерживать: concurrent sessions (несколько транзакций параллельно), timeout handling (если участник не отвечает), session ID для корреляции сообщений.

• Communication layer. Шифрованный P2P канал между участниками. TLS + дополнительное end-to-end шифрование сообщений протокола. Нельзя использовать незашифрованный канал: промежуточные сообщения содержат частичные значения, которые при накоплении могут утечь share.

• HSM/TEE integration. Серверный share хранится в HSM (AWS CloudHSM, Thales) или TEE (Intel SGX, ARM TrustZone). Критично: операции с share выполняются внутри защищённой среды, share никогда не выходит в открытую память. Azure Key Vault Managed HSM и AWS CloudHSM поддерживают custom key operations через PKCS#11 interface.

Протокол восстановления

Важнейший UX-аспект: как пользователь восстанавливает доступ без seed phrase.

• Social recovery MPC. Backup share зашифрован ключами доверенных лиц (guardians). Для восстановления нужно согласие M из N guardians. Реализация: backup share шифруется через threshold encryption для guardian set. Guardian может быть: другое устройство пользователя, email сервис (через KMS), trusted friend (через их публичный ключ), recovery service.

• KMS-based backup. Backup share зашифрован через пользовательский KMS ключ. Для восстановления: пройти KYC/authentication через KMS provider → расшифровать backup share → выполнить re-sharing с новым device share.

Поддержка chain: multi-curve MPC

Разные блокчейны используют разные эллиптические кривые:

TSS для ed25519 отличается от secp256k1: используется схема на основе Schnorr подписей (FROST protocol — Flexible Round-Optimized Schnorr Threshold). FROST проще в реализации, более эффективен по коммуникации. Для production multi-chain кошелька нужно поддерживать оба.

Hierarchical Deterministic (HD) в MPC контексте. Классический BIP32 нельзя применить напрямую: нет единого seed. Решение: threshold BIP32 — каждая сторона хранит свой share для master private key, child key derivation выполняется через MPC операции или через хранение отдельных shares для каждого derived path (менее эффективно, но проще).

Безопасность и аудит

Attack vectors

• Malicious party in signing protocol. Участник может пытаться получить информацию о чужих shares через аномальные сообщения. Защита: range proofs, zero-knowledge доказательства корректности каждого промежуточного значения. CGGMP специально разработан с identifiable abort: протокол может доказать какая сторона ведёт себя злонамеренно.

• Replay attack на signing sessions. Перехваченные сообщения одной signing session не должны использоваться в другой. Защита: session ID включается в каждое сообщение, сессии одноразовые.

• Side-channel через timing. Реализации на Java/Python уязвимы к timing attacks при операциях с большими числами. Production реализации должны использовать constant-time arithmetic (библиотека ct-codecs, Rust subtle crate).

• Compromised communication channel. TLS с certificate pinning + дополнительный authenticated encryption на уровне протокола (каждое MPC сообщение подписывается долгосрочным ключом отправителя).

Рекомендации по аудиту

MPC протокол — криптографически сложный компонент. Аудит должен включать:

• Проверку корректности реализации конкретного протокола (GG20/CGGMP) относительно бумаги
• Анализ side-channel устойчивости
• Fuzz testing signing sessions с аномальными сообщениями
• Verifiable key generation (публичный ключ совпадает с ожидаемым)

Провайдеры для MPC аудита: NCC Group, Kudelski Security, специализируются в cryptographic implementations.

Gennaro & Goldfeder показывают, что threshold ECDSA возможна без восстановления полного ключа, что и лежит в основе production MPC-кошельков.

По сравнению с мультисигом, MPC-кошельки сокращают газовые затраты на 30% и уменьшают сложность on-chain взаимодействия. Финальная подпись неотличима от обычной ECDSA-подписи, что делает MPC идеальным для приватных DeFi-решений.

Готовые библиотеки vs custom реализация

Рекомендация: для большинства проектов — интеграция с Web3Auth MPC Core Kit или Fireblocks MPC SDK вместо написания с нуля. Кастомная реализация MPC протокола требует глубокой экспертизы в прикладной криптографии и занимает 6–12 месяцев. Ошибка в MPC реализации = потенциальная утечка приватных ключей пользователей.

Что входит в работу

• Архитектурная документация с выбором протокола, схемы хранения shares и recovery-модели.
• Реализация core MPC: keygen, signing, key refresh на базе проверенной библиотеки.
• Интеграция с HSM/TEE для серверной ключевой доли.
• Поддержка multi-chain: ECDSA, EdDSA, HD derivation.
• Реализация recovery flows: social recovery или KMS-based backup.
• Криптографический аудит от партнёров (NCC Group, Kudelski Security).
• SDK для мобильных и веб-приложений.
• Пост-релизная поддержка и мониторинг.

Мы также предоставляем обучение команды заказчика по безопасному использованию MPC-кошелька.

Этапы разработки

Минимальный production-ready MPC кошелёк (2-of-2, один chain, базовый recovery) — 4–5 месяцев. Полнофункциональный multi-chain с social recovery и HSM — 8–12 месяцев.

Свяжитесь с нами для обсуждения вашего проекта. Получите консультацию по MPC-решению для вашего DeFi-протокола или криптовалютного приложения.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

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

1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
6. Интеграция с dApps — EIP-1193, WalletConnect v2.
7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

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

• Исходные коды смарт-контрактов (Solidity/Rust) с документацией
• Backend-сервис MPC-координации (на Go или Rust) с API
• Мобильное приложение (iOS/Android) или браузерное расширение
• Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
• Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
• Документация администратора и пользователя
• Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
• Обучение вашей команды (2-3 сессии)
• Поддержка после запуска — 1 месяц

Сроки и стоимость

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

• Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
• Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
• Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
• Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

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