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-протокола или криптовалютного приложения.