Настройка StackUp для Account Abstraction на ERC-4337

Пользователи DeFi сталкиваются с проблемой: для оплаты газа нужен ETH, но в смарт-кошельке только USDC. Решение — Account Abstraction по ERC-4337, позволяющее спонсировать газ токенами. Однако разработка собственного bundler и paymaster требует месяцев. Мы используем StackUp — готовую инфраструктуру, включающую hosted bundler, paymaster API и SDK userop.js. За 5+ лет в Web3 мы внедрили AA в 20+ проектах на EVM. Экономия на разработке — до 40% (до $15,000 в год) по сравнению с самостоятельным решением.

Как работает интеграция с userop.js?

userop.js — это TypeScript SDK для работы с UserOperations. Он абстрагирует создание, подписание и отправку UserOperations через Bundler. StackUp предоставляет готовый хост для bundler и paymaster, а userop.js — удобную обёртку. Вот типовой код подключения:

import { Client, Presets } from "userop";

// Создание AA клиента
const client = await Client.init(
  `https://api.stackup.sh/v1/node/${STACKUP_API_KEY}`,
  {
    entryPoint: "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789",
  }
);

// Создание SimpleAccount (простейшая реализация AA wallet)
const simpleAccount = await Presets.Builder.SimpleAccount.init(
  signer,        // ethers Signer
  `https://api.stackup.sh/v1/node/${STACKUP_API_KEY}`,
  {
    paymasterMiddleware: Presets.Middleware.verifyingPaymaster(
      `https://api.stackup.sh/v1/paymaster/${STACKUP_API_KEY}`,
      { type: "payg" } // pay-as-you-go спонсирование
    ),
  }
);

// Отправка транзакции
const response = await client.sendUserOperation(
  simpleAccount.execute(
    "0xTargetAddress",
    ethers.utils.parseEther("0"),
    "0xCalldata"
  )
);

const receipt = await response.wait();
console.log(`Transaction included in block ${receipt.receipt.blockNumber}`);

Почему выбирают StackUp вместо самописного решения?

Самописный bundler требует поддержки мемпула, симуляции и безопасности от MEV-атак. StackUp берёт это на себя: их bundler написан на Go, открыт под лицензией Apache 2.0, и уже протестирован в мейннете. Paymaster StackUp использует модель Verifying Paymaster с подписью, что защищает от повторного использования (replay). Экономия времени на разработку — около 4-6 недель, снижение операционных затрат на 30%.

Какие компоненты включает инфраструктура?

Bundler — принимает UserOperations, симулирует их (проверяет валидность без on-chain транзакции), формирует bundle и отправляет в EntryPoint контракт. StackUp поддерживает EntryPoint v0.6 и v0.7.

Paymaster — спонсирование gas. StackUp предоставляет Verifying Paymaster, который подписывает разрешение оплатить газ за конкретный UserOperation. Средства спонсора хранятся на paymaster контракте, пополняются через депозит.

Пошаговая интеграция с StackUp

1. Регистрация в StackUp и получение API-ключа.
2. Инициализация клиента userop.js с указанием endpoint и API-ключа.
3. Создание смарт-аккаунта (SimpleAccount или Safe) с подписантом.
4. Настройка paymaster middleware (verifyingPaymaster с URL).
5. Построение UserOperation с нужным calldata и отправка через клиент.
6. Обработка симуляции и ожидание receipt.
7. Тестирование на тестнете, затем деплой на мейннет.

Частая ошибка — "AA21: didn't pay prefund". Она возникает, когда paymaster не перевёл достаточно средств на EntryPoint. Решение: проверить баланс paymaster и убедиться, что депозит покрывает газ для всех ожидающих UserOperations. StackUp предоставляет API для мониторинга депозита.

Что входит в интеграцию?

• Документация: описание архитектуры, схемы потоков UserOperation, настройка paymaster.
• Код: интеграция userop.js с вашим фронтендом, конфигурация API-ключа, обработка ошибок симуляции.
• Поддержка: помощь в деплое на тестнет/мейннет, мониторинг работы bundler, обновление контрактов при хардфорках.
• Обучение: разбор типовых ошибок (revert в симуляции, неверный nonce, превышение gas limit).

Сравнение StackUp и Pimlico

Выбор между ними на практике определяется SDK и поддерживаемыми смарт-аккаунтами. Если ваш проект использует Safe — Pimlico удобнее. Для SimpleAccount и кастомных решений — StackUp быстрее. Закажите консультацию для оценки вашей архитектуры.

Типичный таймлайн интеграции

Собственный bundler через stackup-bundler

Для проектов, требующих независимости от внешней инфраструктуры, StackUp предоставляет open-source bundler на Go:

# Запуск через Docker
docker run -e ERC4337_BUNDLER_ETH_CLIENT_URL=https://mainnet.infura.io/v3/KEY \
  -e ERC4337_BUNDLER_PRIVATE_KEY=0x... \
  -p 4337:4337 stackupwallet/stackup-bundler:latest

Bundler подключается к Ethereum ноде, управляет mempool UserOperations, выполняет simulation перед включением в bundle.

Какой стек используется?

• Ethereum L1/L2: Ethereum, Polygon, Arbitrum, Optimism, Base.
• Языки: Solidity 0.8.x, TypeScript.
• Инструменты: Foundry (тесты контрактов), Tenderly (отладка), Slither (аудит).

Сколько времени занимает интеграция?

Стандартный AA флоу — 1-2 недели. Если нужен кастомный paymaster или поддержка нескольких сетей — до 3 недель. Стоимость рассчитывается индивидуально после анализа проекта. Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальную конфигурацию paymaster и bundler. Получите консультацию по интеграции StackUp в ваш проект. Закажите оценку вашей архитектуры.

Мы разрабатываем криптокошельки под ключ — от 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.

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