Реализация мультиподписи (Multisig) в мобильном криптокошельке
Подписать транзакцию одним приватным ключом — рискованно. Если ключ украден или скомпрометирован, все активы потеряны. Мультиподпись решает эту проблему, требуя несколько независимых подтверждений. В мобильных кошельках мы внедряем два подхода: Smart Contract (Safe/Gnosis) и MPC (Multi-Party Computation). Наш опыт — 30+ блокчейн-проектов — показывает, что правильный выбор схемы определяет и безопасность, и UX.
Gnosis Safe — один из самых популярных смарт-контрактов для мультиподписи, а протокол GG20/GG21 используется в MPC-решениях (см. документацию Safe и википедию о мультиподписи).
Multisig на мобильном — не просто «нужно N из M подписей». Это координация между устройствами или людьми, управление состоянием подписания, хранение pending-транзакций и UX, при котором пользователь понимает где он находится в процессе. Стек и сложность сильно зависят от того, что именно под словом «мультиподпись».
Два подхода: Safe vs MPC — что выбрать?
| Критерий | Safe (Smart Contract) | MPC (Threshold ECDSA) |
|---|---|---|
| On-chain след | Да, каждая подпись подтверждается | Нет, только финальная подпись |
| Гибкость | Любой контракт, но высокий газ | Любой контракт, низкий газ |
| Задержка подписи | Мгновенно (офчейн голосование) | 200–500 ms на signing round |
| Безопасность | Зависит от смарт-контракта | Ключ физически не собирается |
| Сложность интеграции | Низкая (SDK) | Высокая (нативные библиотеки) |
Smart contract multisig (Safe/Gnosis). Смарт-контракт проверяет N подписей перед исполнением. Транзакция хранится в контракте как pending. Каждый подписант независимо подтверждает через approveHash. Простое решение для командного кошелька. Мобильное приложение — это клиент к Safe Transaction Service API (safe-transaction-service), который хранит pending-транзакции офчейн.
MPC (Multi-Party Computation). Приватный ключ физически никогда не собирается в одном месте. Каждая сторона хранит shard ключа, подпись генерируется совместно через протоколы GG20 или CGGMP21 (Threshold ECDSA). Сложнее в реализации, нет onchain-следа, работает с любым контрактом.
Для потребительских кошельков чаще нужен MPC (1 shard на устройстве, 1 на сервере — схема 2-of-2 для защиты от кражи устройства). Для корпоративных — Safe 3-of-5.
Сравним: MPC обеспечивает до 2 раз меньшие газовые затраты, чем Safe, при большом количестве подписей, так как onchain фиксируется только финальная подпись. Однако Safe проще в интеграции и прозрачнее для аудита.
Как настроить Safe multisig на мобильном
Интеграция через Safe{Core} SDK:
import { SafeFactory, SafeAccountConfig } from '@safe-global/protocol-kit' const safeAccountConfig: SafeAccountConfig = { owners: [owner1Address, owner2Address, owner3Address], threshold: 2, } const safeFactory = await SafeFactory.create({ ethAdapter }) const safe = await safeFactory.deploySafe({ safeAccountConfig }) Для подписания pending-транзакции:
const safeTransaction = await safe.createTransaction({ transactions: [{ to, data, value }] }) const txHash = await safe.getTransactionHash(safeTransaction) const signature = await safe.signTransactionHash(txHash) await safeTxService.proposeTransaction({ safeAddress, safeTransactionData: safeTransaction.data, safeTxHash: txHash, senderSignature: signature.data }) Второй подписант получает push-уведомление, видит детали транзакции, подтверждает своей подписью. Когда набралось N — приложение отправляет executeTransaction.
Почему мультиподпись критична для безопасности?
Одиночный приватный ключ — единственная точка отказа. При краже устройства злоумышленник получает полный доступ к средствам. Мультиподпись устраняет эту уязвимость: даже если устройство скомпрометировано, без второго подписанта (например, серверного shard или второго мобильного) транзакция не пройдёт. Мы гарантируем корректную реализацию как для Safe, так и для MPC, с аудитом безопасности на каждом этапе.
Как выбрать между Safe и MPC?
Решение зависит от сценария:
- Командный кошелёк с контролем мультиподписи: Safe — прозрачно, просто, легко аудировать.
- Защита от кражи устройства: MPC 2-of-2 (устройство + сервер) — ключ не покидает shard, даже при взломе сервера.
- Конфиденциальность транзакций: MPC — нет onchain-следа голосования.
MPC: что реализуем нативно
Для схемы 2-of-2 (телефон + сервер) используем библиотеки с открытым кодом: tss-lib (Go), multi-party-ecdsa (Rust). На мобильном — нативный модуль (Swift/Kotlin) с биндингами к Rust через UniFFI или C FFI.
Подробнее о генерации ключей (keygen)
Keygen — однократный обмен сообщениями между устройством и сервером через WebSocket. Результат: каждая сторона получает свой shard, хранит у себя, полный ключ не существует нигде. После keygen можно подписывать транзакции.Подпись транзакции: interactive signing round (2–4 round-trip сообщения), занимает 200–500мс при хорошем соединении. Это приемлемо, но нужно показывать прогресс.
Управление pending-транзакциями в UI
Список транзакций со статусами: pending_signatures (сколько из N собрано), ready (можно исполнять), executed, rejected. Каждая транзакция — детали: адрес получателя, сумма, данные вызова (декодированные если известен ABI). Уведомление подписантам через FCM/APNs.
Что входит в работу
- Аудит требований и выбор схемы (Safe или MPC).
- Архитектура: схема хранения shard-ов, push-уведомления, deep linking.
- Интеграция: Safe Transaction Service (1–2 недели) или нативный MPC модуль (1–3 месяца).
- Тестирование: корректность подписания, обработка edge-кейсов (отказ подписанта, таймауты).
- Документация и код-ревью.
- Поддержка после деплоя.
Процесс и сроки
| Этап | Длительность |
|---|---|
| Аналитика и выбор подхода | 1–2 дня |
| Проектирование схемы | 3–5 дней |
| Интеграция (Safe) | 1–2 недели |
| Интеграция (MPC) | 1–3 месяца |
| Тестирование и аудит | 1–2 недели |
| Деплой и документация | 3–5 дней |
Стоимость рассчитывается индивидуально после оценки объёма работ. Закажите консультацию, и мы предложим оптимальное решение под ваш бюджет.
Типичные ошибки
- Не учитывать коммуникационные задержки в MPC — показать прогресс.
- Не реализовать fallback при недоступности сервера (для MPC с сервером).
- Пренебрегать проверкой подлинности push-уведомлений (возможность фейковых запросов).
Получите готовое решение мультиподписи под ключ. Свяжитесь с нами для анализа вашего проекта.