Разработка Web3-кошельков: от custodial до Account Abstraction
Приватный ключ в MetaMask — это seed-фраза из 12 слов в браузерном расширении. Для розничного пользователя это неприемлемо. Для корпоративного казначейства — тем более. Выбор архитектуры кошелька определяет компромисс между удобством, безопасностью и регуляторной совместимостью. И этот выбор нужно делать на этапе проектирования, не после.
Custodial vs Non-custodial: в чём реальная разница
Custodial кошелёк — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление аккаунта тривиально. KYC/AML интегрируется на стороне провайдера. Для централизованных приложений с финансовыми операциями — иногда единственный регуляторно приемлемый вариант.
Проблема: провайдер — single point of failure и доверия. Если провайдер взломан (Bitfinex 2016, $72M; FTX 2022, $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 costs, нет информации о схеме управления ключами в публичной цепочке.
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. Сторонний контракт платит газ за пользователя. Паттерн для onboarding'а новых пользователей: они вообще не держат 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. От этого зависит выбор архитектуры.
Этапы: выбор и проектирование схемы хранения ключей → разработка Account контракта (если EIP-4337) → backend для MPC-координации (если MPC) → мобильное/браузерное приложение → интеграция с dApps через WalletConnect → аудит контрактов и криптографических реализаций.
Аудит криптографической части — отдельная дисциплина. MPC-библиотеки имеют известные уязвимости: GG18 подвержен атаке при malicious participant без abort protocol. Нужно использовать библиотеки с актуальными security review.
Сроки
Custodial кошелёк с базовым UI — 4-8 недель. Non-custodial с MPC интеграцией — 8-16 недель. EIP-4337 Account с paymaster и сессионными ключами — 6-12 недель. Институциональное решение с HSM, multi-jurisdiction MPC, compliance модулем — от 4 месяцев.