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 — значні втрати, FTX — понад значну суму клієнтських коштів).

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 транзакції та батчинг операцій.

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 день — зв'яжіться з нами. Надаємо гарантію на код та 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.

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