Реалізація мультиподписи в мобільному крипто-кошельку
Multisig на мобільному — не просто "потрібно N з M підписів". Це координація між пристроями або людьми, управління станом підписання, зберігання pending-транзакцій та UX, при якому користувач розуміє де він знаходиться. Стек та складність сильно залежать від того, що саме під словом "мультиподпис".
Два зовсім різних підходи
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.
Реалізація 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.
MPC: що реалізуємо нативно
Для схеми 2-of-2 (телефон + сервер) використовуємо бібліотеки з відкритим кодом: tss-lib (Go), multi-party-ecdsa (Rust). На мобільному — нативний модуль (Swift/Kotlin) з биндингами до Rust через UniFFI або C FFI.
Keygen — однократний обмін повідомленнями між пристроєм та сервером через WebSocket. Результат: кожна сторона отримує свій shard, зберігає у себе, повний ключ не існує нігде.
Підпис транзакції: interactive signing round (2–4 round-trip повідомлень), займає 200–500мс при хорошому з'єднанні. Прийнятно, але потрібно показувати прогрес.
Управління pending-транзакціями в UI
Список транзакцій зі статусами: pending_signatures (скільки з N собрано), ready (можна виконувати), executed, rejected. Кожна транзакція — деталі: адреса одержувача, сума, дані виклику (декодовані якщо відомий ABI). Сповіщення підписантам через FCM/APNs.
Процес
Аудит вимог: Safe vs MPC, кількість підписантів, flow сповіщень. Safe-інтеграція — 1–2 тижні (SDK + Safe Transaction Service + UI). MPC з нативними бібліотеками — 1–3 місяці (keygen, signing, тестування коректності, аудит безпеки). Вартість рассчитується індивідуально.