Ми будуємо кастодіальні MPC-гаманці, де приватний ключ ніколи не існує в повній формі на жодному пристрої. Замість цього кожна сторона тримає «частку» (share) ключа, і підпис транзакції обчислюється спільно через MPC протокол. Вкрасти один share марно — для підпису потрібні всі учасники схеми. Така архітектура усуває single point of failure і робить гаманець стійким до компрометації серверів: навіть якщо зловмисник отримає доступ до серверного share, він не зможе підписати транзакцію без частки користувача. Наші інженери мають 10+ років досвіду в блокчейн-розробці та криптографії. Ми гарантуємо, що ваш сервіс отримає захист рівня institutional custody без єдиної точки відмови. Це корпоративне зберігання крипти на новому рівні — гаманець без seed phrase, де доступ відновлюється через backup share.
Це принципова відмінність від традиційного мультисигу (M-of-N on-chain): мультисиг видимий у блокчейні, потребує N підписів on-chain (газ), і факт використання мультисигу публічний. MPC-підпис виглядає як звичайний одиночний підпис — ні блокчейн, ні спостерігач не бачить, що за ним стоїть спільне обчислення. Fireblocks, ZenGo, Coinbase WaaS, Web3Auth — MPC-based продукти. Банківський та institutional сектор переходить на MPC саме через відсутність single point of failure при зберіганні ключів. Економія на газі сягає 50% порівняно з on-chain мультисигом.
Як працює MPC-гаманець?
Threshold Signature Scheme (TSS)
Для Ethereum (secp256k1) найпоширеніший GG20 протокол (Genaro-Goldfeder 2020) або його покращення CGGMP21. Схема t-of-n: будь-які t з n учасників можуть обчислити підпис, без t — неможливо.
Процес складається з двох фаз:
-
Keygen (distributed key generation): учасники інтерактивно генерують shares, не розкриваючи фінальний ключ. По закінченні кожен має
share_i, а публічний ключP = G * privateKeyвідомий всім. Приватний ключprivateKeyне існує ніде. -
Signing: для підпису транзакції t учасників запускають MPC протокол, кожен вводить свій
share_i, на виході — валідний ECDSA підпис. Жоден учасник не дізнався ключі інших.
Реальні MPC бібліотеки
Production-готові реалізації:
- tss-lib (Binance): Go бібліотека, реалізує GG18/GG20. Використовується в Binance Chain, Thorchain. Відкритий вихідний код.
- multi-party-ecdsa (ZenGo): Rust, реалізує GG20. Більш актуальна, активна підтримка.
- @sodot/sodot-node-sdk: комерційне SDK для MPC-as-a-service. Швидкий старт, не потрібно реалізовувати протокол самостійно.
- Silence Laboratories SDK: академічно верифікована реалізація, використовується в Web3Auth для MPC as a service.
Самостійна реалізація MPC протоколу — це місяці роботи криптографа та високий ризик помилок. Для більшості проєктів правильний вибір — готова бібліотека або MPC-as-a-service.
Вибір MPC-бібліотеки
| Бібліотека | Мова | Протокол | Ліцензія | Особливості |
|---|---|---|---|---|
| tss-lib (Binance) | Go | GG18/GG20 | Open source | Перевірена в Binance Chain, Thorchain |
| multi-party-ecdsa (ZenGo) | Rust | GG20 | Open source | Активна підтримка, аудит |
| Sodot SDK | TypeScript | CGGMP21 | Комерційна | Fast integration, MPC-as-a-service |
| Silence Laboratories SDK | Rust/Python | Академічний | Комерційна | Формальна верифікація |
Чому MPC-гаманець кращий за мультисиг?
| Критерій | MPC Wallet | On-chain Multisig |
|---|---|---|
| Видимість у блокчейні | Звичайний підпис | N підписів публічно |
| Газ за транзакцію | Звичайний | +20-50% (додаткові підписи) |
| Single point of failure | Відсутній | Залежить від конфігурації |
| Recovery при втраті пристрою | Через backup share | Через інших підписантів |
| Сумісність | Будь-який EVM гаманець | Потребує multisig aware dApp |
| Складність реалізації | Висока | Низька (Gnosis Safe) |
MPC виправданий для: institutional custody, wallets-as-a-service, гаманців без seed phrase (mobile-first), вбудованих гаманців у додатки. Gnosis Safe (on-chain multisig) виправданий для: DAO treasury, team wallets, випадків де потрібна максимальна прозорість on-chain.
Архітектура 2-of-2 MPC гаманця
Типова схема для consumer гаманця: одна частка на пристрої користувача, одна на сервері. Транзакція потребує участі обох сторін.
Сервер не знає повного ключа. Пристрій не знає повного ключа. Без сервера користувач не може підписати (захист від крадіжки пристрою). Без пристрою сервер не може підписати (сервер не може вкрасти кошти).
Keygen flow
// Спрощена ілюстрація flow (не production-ready код)
import { MpcSigner } from '@sodot/sodot-node-sdk';
class MPCWallet {
private deviceSdk: MpcSigner;
private serverSdk: MpcSigner;
async generateKey(): Promise<string> {
const keygenId = crypto.randomUUID();
const [deviceShare, serverShare] = await Promise.all([
this.deviceSdk.initKeygen(keygenId, { threshold: 2, parties: 2, partyIndex: 1 }),
this.serverSdk.initKeygen(keygenId, { threshold: 2, parties: 2, partyIndex: 2 }),
]);
await this.runKeygenRounds(keygenId, deviceShare, serverShare);
const publicKey = await this.deviceSdk.getPublicKey(keygenId);
const address = ethers.computeAddress('0x' + publicKey);
await this.deviceSdk.storeShare(keygenId, deviceShare);
await this.serverSdk.storeShare(keygenId, serverShare);
return address;
}
async signTransaction(address: string, transaction: ethers.TransactionRequest): Promise<string> {
await this.authenticateUser();
const txHash = ethers.keccak256(ethers.Transaction.from(transaction).unsignedSerialized);
const signingId = crypto.randomUUID();
const signature = await this.runSigningProtocol(signingId, txHash, address);
const signedTx = ethers.Transaction.from({ ...transaction, signature });
return signedTx.serialized;
}
}
Share refresh (proactive security)
Share refresh вирішує проблему компрометації серверного share: учасники періодично оновлюють свої shares без зміни підсумкового ключа. Вкрадений share рік тому сьогодні марний.
async function refreshShares(walletId: string): Promise<void> {
await Promise.all([
deviceSdk.refreshShare(walletId),
serverSdk.refreshShare(walletId),
]);
}
setInterval(() => {
for (const walletId of activeWallets) {
refreshShares(walletId).catch(console.error);
}
}, 7 * 24 * 60 * 60 * 1000);
Відновлення доступу при втраті пристрою
Схема 2-of-2 має слабке місце: якщо сервер недоступний, користувач не може підписати транзакції. Схема 2-of-3 вирішує це:
- Share 1: пристрій користувача
- Share 2: сервер (онлайн signing)
- Share 3: backup (зашифрований паролем користувача, зберігається в хмарі або роздрукований)
При нормальній роботі: Device + Server = підпис. Якщо сервер недоступний: Device + Backup = підпис (аварійний recovery). Якщо пристрій втрачено: Server + Backup = відновлення на новий пристрій.
| Схема | Поріг | Учасники | Recovery | Використання |
|---|---|---|---|---|
| 2-of-2 | 2 | Device + Server | Через backup share | Consumer wallets |
| 2-of-3 | 2 | Device + Server + Backup | Device lost: Server+Backup | Enterprise custody |
async function recoverToNewDevice(
backupShare: CloudEncryptedShare,
backupPassword: string
): Promise<string> {
const decryptedBackup = await decryptBackupShare(backupShare, backupPassword);
await verifyUserIdentity();
const newDeviceShare = await sdk.refreshWithParties([serverShare, decryptedBackup]);
await secureStore.save(newDeviceShare);
return 'Recovery complete';
}
Комунікаційний канал між сторонами: MPC протокол потребує кількох раундів обміну повідомленнями між учасниками. Для 2-of-2 (пристрій + сервер) оптимальний WebSocket — мінімальна затримка. REST polling простіший, але додає 0.5-2.5 секунди до підпису. Типовий час підпису через MPC: 0.5-2 секунди при хорошій мережі. Показуємо прогрес в UI.
Серверна інфраструктура
Серверний share повинен зберігатися в Hardware Security Module (HSM) — фізичному пристрої, з якого неможливо витягти ключ програмно. Варіанти: AWS CloudHSM (FIPS 140-2 Level 3), AWS KMS (софт), HashiCorp Vault (self-hosted). Для стартапу достатньо AWS KMS + encryption at rest. HSM — при зростанні до institutional клієнтів.
Аутентифікація перед signing
Сервер перевіряє, що запит на підпис ініційований авторизованим користувачем (JWT після біометрії). Додатково застосовуються політики транзакцій: ліміти, whitelist адрес, вимога додаткової верифікації для великих сум.
Що входить в роботу
При замовленні розробки кастодіального MPC-гаманця ви отримуєте:
- Архітектурний дизайн та вибір MPC протоколу (t-of-n схема)
- Інтеграцію MPC бібліотеки (tss-lib / multi-party-ecdsa / Sodot SDK)
- Реалізацію keygen та signing flow з share storage
- Розробку мобільного/веб-додатку з UX для onboarding, транзакцій та recovery
- Серверну частину: auth service, signing API, policy engine, HSM інтеграцію
- Security review та pentest (MPC протокол + інфраструктура) — повний аудит безпеки гаманця
- Документацію, навчання команди, підтримку на етапі запуску
Процес роботи
- Архітектурний дизайн (1-2 тижні): вибір MPC протоколу, share distribution, backup/recovery flows, серверна інфраструктура.
- Keygen та signing реалізація (3-4 тижні): інтеграція MPC бібліотеки, комунікаційний канал, share storage.
- Мобільний/веб додаток (2-3 тижні): UX onboarding, transaction flow, progress indicators, recovery UI.
- Серверна частина (2-3 тижні): auth, signing API, policy engine, HSM інтеграція.
- Security review (2 тижні): протокол security analysis, pentest, share storage review.
- Тестування та launch (1-2 тижні): end-to-end тести, навантажувальне тестування.
Повний цикл MPC гаманця: 4-6 місяців. Це складніше звичайного гаманця через MPC протокол та необхідність криптографічної експертизи. Вартість розраховується після деталізації схеми та вибору MPC бібліотеки.
Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами, щоб обговорити архітектуру. Також вивчіть Secure multi-party computation для загального розуміння технології. Отримайте консультацію по вашому проєкту — наші інженери відповідають на технічні питання.