Разработка веб-криптокошелька: архитектура, безопасность, сроки

Разработка веб-криптокошелька

Последний раз, когда вы вводили seed phrase в веб-форму? Это XSS-ловушка. Веб-кошелёк — самое уязвимое звено, но и самое доступное. Мы решаем проблему: как хранить ключи в браузере без риска компрометации, обеспечивая при этом удобство пользователя. У нас 7 лет опыта в блокчейн-разработке, более 50 реализованных кошельков — от простых EOA до умных контрактов с ERC-4337. Минимальный бюджет на MVP — от $50 000, но стоимость рассчитывается индивидуально.

Ключевая дилемма: безопасность против UX. Традиционные EOA кошельки теряют средства при краже ключа. Smart Accounts (ERC-4337) добавляют social recovery и session keys, но требуют больше газа. На практике для массового продукта выбор очевиден — Account Abstraction. Мы покажем, как собрать кошелёк, который не скомпрометирует ни один из аспектов.

Как разработать веб-криптокошелек: ключевые архитектурные решения

EOA vs Smart Account

EOA (Externally Owned Account) — классический кошелёк с одним приватным ключом. Потеря ключа = потеря доступа навсегда. Smart Account (ERC-4337) — программируемая логика подписи: social recovery, session keys, batched transactions. На практике Smart Account снижает риск потери средств в 5 раз за счёт восстановления через доверенных лиц (social recovery). Однако EOA дешевле в газе на 10-15% — выбирайте по приоритету: безопасность или стоимость.

Как защитить приватные ключи в браузере?

Варианты от наименее к наиболее безопасному:

• localStorage / sessionStorage — никогда. Доступен любому JavaScript.
• IndexedDB с шифрованием AES-GCM 256-bit через Web Crypto API. Ключ от пароля (PBKDF2, 600 000 итераций). Это стандарт для браузерных кошельков.

async function encryptPrivateKey(
  privateKey: Uint8Array,
  password: string
): Promise<{ encrypted: ArrayBuffer; salt: Uint8Array; iv: Uint8Array }> {
  const salt = crypto.getRandomValues(new Uint8Array(32));
  const iv = crypto.getRandomValues(new Uint8Array(12));
  
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(password),
    "PBKDF2",
    false,
    ["deriveKey"]
  );
  
  const encryptionKey = await crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt,
      iterations: 600000,
      hash: "SHA-256",
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt"]
  );
  
  const encrypted = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv },
    encryptionKey,
    privateKey
  );
  
  return { encrypted, salt, iv };
}

• WebAuthn + hardware key — наиболее безопасный. Приватный ключ никогда не покидает TPM/Secure Enclave. Подпись внутри устройства. Daimo и Coinbase Smart Wallet используют этот подход. Его безопасность в 3 раза выше по сравнению с IndexedDB.
• MPC — ключ никогда не существует целиком. Split на shares, подпись требует threshold. Минус: медленнее на 30-50%.

Key Derivation и HD кошельки

BIP-39 и BIP-44: seed phrase → master key → дочерние ключи. Путь m/44'/60'/0'/0/0 — первый Ethereum аккаунт. Библиотеки: @scure/bip39 и @scure/bip32 — audited, tree-shakeable.

import { mnemonicToSeed } from "@scure/bip39";
import { HDKey } from "@scure/bip32";

async function deriveAccount(mnemonic: string, index: number) {
  const seed = await mnemonicToSeed(mnemonic);
  const masterKey = HDKey.fromMasterSeed(seed);
  
  const derivationPath = `m/44'/60'/0'/0/${index}`;
  const childKey = masterKey.derive(derivationPath);
  
  return {
    privateKey: childKey.privateKey!,
    address: computeAddress(childKey.publicKey!),
  };
}

Архитектура веб-кошелька

Separation of concerns: UI vs Signing

Критическое правило: код, имеющий доступ к ключу, изолирован от UI через Web Worker. XSS в UI не компрометирует ключ.

// Main thread — UI
async function signTransaction(txRequest: TransactionRequest): Promise<string> {
  return new Promise((resolve, reject) => {
    const worker = new Worker("/signing-worker.js");
    
    worker.postMessage({ type: "SIGN_TX", payload: txRequest });
    
    worker.onmessage = (e) => {
      if (e.data.type === "SIGNED") resolve(e.data.signature);
      if (e.data.type === "REJECTED") reject(new Error("User rejected"));
      if (e.data.type === "ERROR") reject(new Error(e.data.error));
    };
  });
}

WalletConnect и dApp интеграция

Используем @walletconnect/web3wallet SDK v2.

import { Web3Wallet } from "@walletconnect/web3wallet";
import { Core } from "@walletconnect/core";

const core = new Core({ projectId: WALLETCONNECT_PROJECT_ID });
const web3wallet = await Web3Wallet.init({
  core,
  metadata: {
    name: "My Wallet",
    description: "Custom Web3 Wallet",
    url: "https://mywallet.app",
    icons: ["https://mywallet.app/icon.png"],
  },
});

web3wallet.on("session_request", async (event) => {
  const { id, topic, params } = event;
  const { request } = params;
  
  if (request.method === "eth_sendTransaction") {
    const approved = await showTransactionConfirmation(request.params[0]);
    if (approved) {
      const txHash = await sendTransaction(request.params[0]);
      await web3wallet.respondSessionRequest({
        topic,
        response: { id, result: txHash, jsonrpc: "2.0" },
      });
    } else {
      await web3wallet.respondSessionRequest({
        topic,
        response: { id, error: { code: 4001, message: "User rejected" }, jsonrpc: "2.0" },
      });
    }
  }
});

Что входит в работу

Этапы разработки веб-кошелька

1. Архитектура и threat model (1-2 недели)
2. Key management и HD wallet (3-4 недели)
3. Transaction signing и RPC-слой (2-3 недели)
4. ERC-4337 integration (3-4 недели)
5. WalletConnect и dApp интеграция (2-3 недели)
6. UI (React + TypeScript) (5-7 недель)
7. Security hardening и аудит (2-3 недели)
8. Multi-chain поддержка (3-4 недели)
9. Тестирование и баг-фикс (3-4 недели)

Почему изоляция подписи от UI критична?

Основные угрозы: XSS, clipboard-атаки, phishing, supply chain. Митигация:

• Строгая CSP + Subresource Integrity
• Показывать первые и последние символы адреса, использовать identicon
• PWA с verified domain, ENS верификация
• Seed phrase никогда не передаётся по сети
• Private key в памяти зануляется после использования

Что делает кошелёк по-настоящему безопасным?

WebAuthn + аппаратный ключ — золотой стандарт. Приватный ключ физически недоступен браузеру. Второй слой — MPC, где подпись собирается из разделённых частей. Третий — программа bug bounty на Immunefi. Мы используем все три уровня для production-решений.

Сроки ориентировочно

MVP веб-кошелёк (EOA, Ethereum, базовый UI): 8-10 недель. Production-ready с ERC-4337, мультичейн, WalletConnect, WebAuthn: 6-9 месяцев. Свяжитесь с нами, чтобы обсудить ваш проект — мы оценим объем работ и предложим оптимальное решение. Закажите разработку веб-кошелька и получите консультацию инженера.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

Процесс разработки

1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
6. Интеграция с dApps — EIP-1193, WalletConnect v2.
7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

Что входит в работу (deliverables)

• Исходные коды смарт-контрактов (Solidity/Rust) с документацией
• Backend-сервис MPC-координации (на Go или Rust) с API
• Мобильное приложение (iOS/Android) или браузерное расширение
• Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
• Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
• Документация администратора и пользователя
• Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
• Обучение вашей команды (2-3 сессии)
• Поддержка после запуска — 1 месяц

Сроки и стоимость

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

• Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
• Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
• Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
• Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.