Мы строим кастодиальные 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 для общего понимания технологии. Получите консультацию по вашему проекту — наши инженеры ответят на технические вопросы.