Розробка кастодіального гаманця

Розробка MPC-гаманця

MPC (Multi-Party Computation) — криптографічний протокол при якому кілька сторін спільно вичислюють функцію над своїми секретними даними не розкриваючи ці дані один одному. Застосовано до гаманців: приватний ключ ніколи не існує повністю в одному місці. Замість того, кожна сторона тримає «долю» (share) ключа, та підпис транзакції вичислюється спільно через MPC протокол. Украсти один share — марно — для підпису потрібні всі учасники схеми.

Принципіальне розходження від традиційного мультисигу (M-of-N on-chain): мультисиг видно в блокчейні, вимагає N підписів on-chain (газ), та факт використання мультисигу публічний. MPC-підпис виглядає як звичайний одиничний підпис — ні блокчейн, ні спостерігач не бачать спільного вичислення за ним.

Fireblocks, ZenGo, Coinbase WaaS, Web3Auth — MPC-based продукти. Банківський та institutional сектор переходить на MPC саме через відсутність single point of failure при зберіганні ключів.

Криптографічна основа

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 підпись. Жоден учасник не дізнається ключи інших.

Класичний гаманець:
  privateKey → address (публічний ключ)
  підпис: sign(tx, privateKey)

MPC 2-of-3 гаманець:
  share_1 (сервер), share_2 (пристрій), share_3 (backup)
  address = publicKey (похідний від shares, але ключ не існує)
  підпис: MPC_sign(tx, share_1, share_2)  ← будь-які 2 з 3

Реальні MPC бібліотеки

Production-готові реалізації:

tss-lib (Binance): Go бібліотека, реалізує GG18/GG20. Використовується в Binance Chain, Thorchain. Open source.

multi-party-ecdsa (ZenGo): Rust, реалізує GG20. Більш актуальна, активна підтримка.

@sodot/sodot-node-sdk: комерційне SDK для MPC-as-a-service. Швидкий старт, не потрібно реалізовувати протокол.

Silence Laboratories SDK: академічно верифікована реалізація, використовується в Web3Auth MPC.

Самостійна реалізація MPC протоколу — місяці роботи криптографа та високий ризик помилок. Для більшості проектів — правильний вибір — готова бібліотека або MPC-as-a-service.

Архітектура 2-of-2 MPC гаманця

Типова для consumer гаманця: одна доля на пристрої користувача, одна на сервері. Транзакція вимагає участі обох сторін.

Пристрій (Share A)   ←→   Сервер (Share B)
        ↑
   Користувач авторизує

Сервер не знає повного ключа. Пристрій не знає повного ключа. Без сервера користувач не може підписати (захист від крадіжки пристрою). Без пристрою сервер не може підписати (сервер не може украсти кошти).

Keygen flow

// Упрощена ілюстрація (не production-готовий код)
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 }),
    ]);

    // Кілька раундів обміну повідомленнями (GG20 вимагає 3-5 раундів)
    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 витік, та ми дізнались про це сьогодні — весь період ми були уразливі. Share refresh вирішує: періодично (раз у тиждень/місяць) учасники оновлюють свої shares без зміни итогового ключа. Старі shares стають невалідними. Украдений share рік назад сьогодні безглузд.

async function refreshShares(walletId: string): Promise<void> {
  await Promise.all([
    deviceSdk.refreshShare(walletId),
    serverSdk.refreshShare(walletId),
  ]);
}

// Автоматичний refresh по розписанню
setInterval(() => {
  for (const walletId of activeWallets) {
    refreshShares(walletId).catch(console.error);
  }
}, 7 * 24 * 60 * 60 * 1000); // кожного тижня

2-of-3 з backup share

Схема 2-of-2 має слабе місце: якщо сервер недоступний, користувач не може підписати транзакції. Схема 2-of-3 вирішує:

• Share 1: пристрій користувача
• Share 2: сервер (online signing)
• Share 3: backup (зашифрований паролем користувача, в хмарі або роздрукований)

При нормальній роботі: Device + Server = підпис. Якщо сервер недоступний: Device + Backup = підпис (аварійне відновлення). Якщо пристрій втрачений: Server + Backup = відновлення на новому пристрої.

interface ShareDistribution {
  deviceShare: EncryptedShare;
  serverShare: ServerShare;
  backupShare: CloudEncryptedShare;
}

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: мінімальна latency, потрібен persistent connection. Оптимально для мобільних.

REST polling: простіше в реалізації, більша latency (100-500ms per round). Для 3-5 раундів GG20 — додаткові 0.5-2.5 секунди.

Типове час підпису через MPC: 0.5-2 секунди при хорошій мережі. Для користувача — помітно довше ніж локальний підпис (< 10ms). Показуйте прогрес в UI.

Серверна інфраструктура

HSM для серверних shares

Серверний share повинен зберігатися в Hardware Security Module — фізичному пристрої з якого неможливо витягнути ключ через програмний інтерфейс. Варіанти:

AWS CloudHSM: дорого ($1.4K/month per HSM), але enterprise-grade. FIPS 140-2 Level 3 відповідність.

AWS KMS (software): дешевше, не справжній HSM, але достатньо для більшості.

HashiCorp Vault: self-hosted, підтримує інтеграцію з апаратними HSM, auto-unseal через KMS.

Для стартапу: AWS KMS + encryption at rest достатньо спочатку. HSM — при розростанні до institutional клієнтів.

Аутентифікація перед signing

Сервер повинен переконатися що запит на підпис ініціирован авторизованим користувачем:

async function authorizeSigningRequest(
  walletId: string,
  txHash: string,
  authToken: string
): Promise<boolean> {
  const payload = await verifyJWT(authToken);

  if (payload.walletId !== walletId) return false;
  if (payload.exp < Date.now() / 1000) return false;

  const tx = parseTransaction(txHash);
  const policy = await getUserPolicy(walletId);

  if (tx.valueUSD > policy.dailyLimit) {
    await requireAdditionalVerification(walletId, tx);
  }

  return true;
}

Переваги MPC vs класичного мультисигу

MPC виправданий для: institutional custody, wallets-as-a-service, гаманців без seed phrase (mobile-first), вбудованих гаманців у програми.

Gnosis Safe (on-chain multisig) виправданий для: DAO treasury, team wallets, випадків де потрібна максимальна on-chain прозорість.

Стек та бібліотеки

Процес роботи

Архітектурний дизайн (1-2 тижні). Вибір MPC протоколу (t-of-n схема), MPC-as-a-service vs self-hosted, схема розподілу shares, backup та recovery flows, серверна інфраструктура.

Keygen та signing реалізація (3-4 тижні). Інтеграція MPC бібліотеки, коммунікаційний канал, зберігання shares.

Мобільне/web програма (2-3 тижні). UX onboarding, transaction flow з MPC підписом, progress indicators, recovery UI.

Серверна частина (2-3 тижні). Auth сервіс, signing API, policy engine, HSM інтеграція.

Security review (2 тижні). MPC протокол security analysis, серверна інфраструктура pentest, review зберігання shares.

Тестування та запуск (1-2 тижні). End-to-end всіх сценаріїв (normal, device loss, server downtime), load тестування.

Повний цикл MPC гаманця: 4-6 місяців. Складніше ніж звичайний гаманець через MPC протокол та необхідність криптографічної експертизи. Вартість розраховується після деталізації схеми та вибору MPC бібліотеки.