Налаштування StackUp для Account Abstraction на ERC-4337

Користувачі DeFi стикаються з проблемою: для оплати газу потрібен ETH, але в смарт-гаманці лише USDC. Рішення — Account Abstraction за ERC-4337 (EIP-4337), що дозволяє спонсорувати газ токенами. Однак розробка власного bundler та paymaster потребує місяців. Ми використовуємо StackUp — готову інфраструктуру, що включає hosted bundler, paymaster API та SDK userop.js. За 5+ років на ринку Web3 ми впровадили AA у 20+ успішних проєктах на EVM. Економія на розробці — до 40% (до $20,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
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" }
    ),
  }
);

// Відправлення транзакції
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 замість самописного рішення?

StackUp інтегрується у 2 рази швидше, ніж самописне рішення. Самописний 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 — спонсорування газу. 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

StackUp економить до 30% витрат на газ порівняно з Pimlico завдяки pay-as-you-go моделі. Вибір визначається SDK та підтримуваними смарт-акаунтами: для Safe — Pimlico зручніше, для SimpleAccount — StackUp швидше. Зв'яжіться з нами — команда з 10+ сертифікованих інженерів підбере оптимальну конфігурацію.

Типовий таймлайн інтеграції

Власний bundler через stackup-bundler

Для проєктів, що потребують незалежності від зовнішньої інфраструктури, StackUp надає open-source bundler на Go:

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 тижнів. Вартість інтеграції — від $5,000. Гарантія якості: ми надаємо безкоштовний аудит після деплою. Отримайте консультацію з інтеграції 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 — значні втрати, FTX — понад значну суму клієнтських коштів).

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 транзакції та батчинг операцій.

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 день — зв'яжіться з нами. Надаємо гарантію на код та 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.

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