Мы разрабатываем криптокошельки под ключ — от 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).
Процесс разработки
- Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
- Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
- Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
- Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
- Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
- Интеграция с dApps — EIP-1193, WalletConnect v2.
- Аудит контрактов и криптографических реализаций — обязательный этап. 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 месяц
Сроки и стоимость
| Тип решения | Сроки (рабочие недели) |
|---|---|
| Custodial с базовым UI | 4–8 |
| Non-custodial с MPC-интеграцией | 8–16 |
| EIP-4337 Account с paymaster | 6–12 |
| Institutional (HSM + MPC + compliance) | от 16 |
Стоимость рассчитывается индивидуально под ваш проект. Оценим за 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.
Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.