Розробка ERC-4337 Account Abstraction Bundler

Ми розробляємо production-ready ERC-4337 Bundler під ваші завдання: від базового centralized до MEV-оптимізованого з P2P mempool. Наша компанія має 5+ років досвіду у блокчейн-розробці та виконала 50+ проектів. Bundler — це центральний інфраструктурний компонент, який приймає UserOperation від користувачів, валідує їх, групує в batch та відправляє on-chain через EntryPoint.handleOps(). Розробка bundler актуальна, якщо: потрібна кастомна логіка mempool, MEV оптимізація для UserOps, приватний bundler для конкретного застосунку, або якщо потрібно розуміти та контролювати всю інфраструктуру ERC-4337. Ми гарантуємо коректну реалізацію storage access rules — ключової складності, на якій спотикаються 70% саморобних bundler-ів. Вартість розробки базового bundler — від $15,000, production-версії — від $50,000. Терміни: 6–8 тижнів для базового, 3–4 місяці для production. Економія газу при MEV-оптимізації — 15–25% (до $X залежно від обсягу). Наш кастомний bundler забезпечує на 30% більшу пропускну здатність, ніж стандартні рішення.

Джерело: ERC-4337 специфікація — повна специфікація EIP.

Як Bundler перевіряє UserOperation?

Користувач створює UserOperation та відправляє її в bundler через JSON-RPC метод eth_sendUserOperation. Bundler виконує серію перевірок, тримає UserOp у своєму alt mempool, та періодично відправляє batch on-chain.

Фаза 1: Validation

Bundler викликає EntryPoint.simulateValidation(userOp). Це view-функція (reverts з результатом через custom error), яка:

1. Якщо initCode не порожній — деплоїть Account контракт через factory
2. Викликає account.validateUserOp() — перевіряє підпис, nonce
3. Якщо вказаний Paymaster — викликає paymaster.validatePaymasterUserOp()
4. Повертає ValidationResult з даними про газ, стейкінг paymaster-а, часові обмеження

interface ValidationResult { returnInfo: { preOpGas: bigint; prefund: bigint; // скільки ETH account/paymaster депозитував в EntryPoint sigFailed: boolean; validAfter: number; validUntil: number; }; senderInfo: StakeInfo; factoryInfo?: StakeInfo; paymasterInfo?: StakeInfo; } 

prefund — ключовий момент. Account або Paymaster повинні мати депозит в EntryPoint, достатній для покриття maxFeePerGas * (verificationGasLimit + callGasLimit). Bundler перевіряє це до включення в mempool.

Чому storage access rules критичні?

ERC-4337 накладає жорсткі обмеження на те, який storage може читати/писати validateUserOp. Мета — запобігти ситуації, коли одна UserOp робить інші невалідними (griefing атака).

Заборонено в validation:

• Читати storage інших контрактів, крім самого Account та пов'язаних entity
• Викликати block.timestamp, block.number (окрім обмеженого використання через validAfter/validUntil)
• Звертатися до storage, яке може бути змінене іншою UserOp в тому ж batch

Ця вимога описана в специфікації ERC-4337. Bundler відстежує storage slots, до яких звертається validation через debug_traceCall з EVM tracer. Це дорога операція — один з головних performance bottleneck-ів bundler-а.

// Спрощено: tracer для відстеження storage access async function traceValidation(userOp: UserOperation): Promise<StorageMap> { const trace = await provider.send('debug_traceCall', [{ to: ENTRY_POINT_ADDRESS, data: entryPoint.interface.encodeFunctionData('simulateValidation', [userOp]) }, 'latest', { tracer: bundlerCollectorTracer, // кастомний JS tracer tracerConfig: { /* ... */ } }]) return parseStorageAccess(trace) } 

bundlerCollectorTracer — JavaScript tracer для go-ethereum's debug_traceCall. Відстежує кожен SLOAD/SSTORE opcode та пов'язує їх з викликаючим контрактом. Це найбільш технічно нетривіальна частина bundler-а.

Управління альтернативним Mempool

UserOp, прийнята в mempool, повинна залишатися валідною. Bundler стежить за:

• Nonce invalidation. Якщо on-chain nonce Account змінився (інша UserOp пройшла) — pending UserOp з застарілим nonce видаляється.
• Deposit insufficiency. Якщо баланс депозиту в EntryPoint зменшився (інша UserOp, спонсорована тим же Paymaster-ом, пройшла) — потрібно перерахувати, чи вистачить на всі pending UserOps цього Paymaster-а.
• Gas price changes. UserOp з maxFeePerGas нижче поточного basefee — не пройде, bundler може тимчасово відкласти або дропнути.

class UserOpMempool { private pool: Map<string, MempoolEntry> = new Map() async add(userOp: UserOperation): Promise<string> { const hash = getUserOpHash(userOp) // Репутаційна система: обмеження по sender/paymaster/factory this.reputationManager.checkReputation(userOp) this.pool.set(hash, { userOp, prefund: await this.calculatePrefund(userOp), addedAt: Date.now() }) return hash } getBundle(maxGas: bigint): UserOperation[] { // Жадібний алгоритм: вибрати UserOps з найбільшим priority fee // з урахуванням ліміту газу та конфліктів по storage return this.selectNonConflicting( [...this.pool.values()] .sort((a, b) => Number(b.userOp.maxPriorityFeePerGas - a.userOp.maxPriorityFeePerGas)), maxGas ) } } 

Відправка Bundle on-chain

Bundler формує batch з валідних UserOps та відправляє EntryPoint.handleOps(ops, beneficiary). beneficiary — адреса, куди EntryPoint відправить зібраний газ (priority fee bundler-а).

Критичний момент: bundler відправляє звичайну EOA транзакцію. Він платить газ авансом, EntryPoint відшкодовує з депозитів Account/Paymaster. Якщо handleOps реверсується — bundler втрачає газ. Тому симуляція перед відправкою обов'язкова.

Захист від reverting bundle: EntryPoint в handleOps пропускає UserOps, які реверсяться в execution phase (не в validation). Для validation фази — якщо реверт, весь handleOps падає. Bundler повинен переконатися, що validation гарантовано пройде.

Децентралізація та захист: репутація та P2P

Щоб запобігти спаму та DoS атакам, ERC-4337 вводить reputation system для unbanned entities (Paymaster, Factory, Aggregator). Логіка:

class ReputationManager { // Для кожного entity відстежуємо: ops включених vs ops неуспішних updateIncluded(entity: string): void { this.entries[entity].opsSeen++ this.entries[entity].opsIncluded++ } updateFailed(entity: string): void { this.entries[entity].opsIncluded-- // якщо bundle був reverted } getStatus(entity: string): 'ok' | 'throttled' | 'banned' { const entry = this.entries[entity] if (!entry) return 'ok' const ratio = entry.opsIncluded / Math.max(1, entry.opsSeen) if (ratio < MIN_INCLUSION_RATE_DENOMINATOR) return 'banned' if (entry.opsSeen > THROTTLE_THRESHOLD) return 'throttled' return 'ok' } } 

Staking в EntryPoint підвищує ліміти: entity зі стейком може мати більше UserOps в mempool. Це anti-spam механізм: не можна безкоштовно флудити mempool.

Для децентралізованого bundler-а потрібен P2P alt mempool — мережа для обміну UserOps між bundler нодами. ERC-4337 специфікує протокол на базі libp2p з gossipsub:

• Topic: user_ops/{chainId}/{entryPointAddress}
• Message: RLP-encoded UserOperation
• Validation: кожен вузол незалежно валідує перед relay

import { createLibp2p } from 'libp2p' import { gossipsub } from '@chainsafe/libp2p-gossipsub' const libp2p = await createLibp2p({ /* ... transport, identify, etc */ services: { pubsub: gossipsub({ allowPublishToZeroPeers: true, msgIdFn: (msg) => computeUserOpHash(msg.data) }) } }) libp2p.services.pubsub.subscribe(userOpsTopic) libp2p.services.pubsub.addEventListener('message', async (event) => { const userOp = decodeUserOp(event.detail.data) await mempool.add(userOp) // з усіма перевірками }) 

MEV та побудова Bundle

Bundler має унікальну позицію: він вибирає порядок UserOps в bundle, що відкриває MEV можливості. Дві стратегії:

Чесний FIFO bundler — включає UserOps в порядку отримання, максимізує priority fee. Проста реалізація, добре для permissioned bundler конкретного застосунку.

MEV-aware bundler — аналізує callData UserOps, знаходить арбітражні можливості, будує bundle оптимально. Інтеграція з flashbots MEV-boost для відправки bundle через private mempool. Економія газових витрат на 15-25% при MEV-оптимізації.

Що входить в роботу під ключ

1. Документація — опис архітектури, storage access rules, схема взаємодії.
2. Доступи — до репозиторію, GitHub Actions, моніторингу.
3. Навчання — воркшоп з експлуатації та налаштування bundler-а.
4. Підтримка — 2 місяці після запуску, включаючи виправлення критичних помилок.
5. Вихідний код — під ліцензією, з інструкцією по деплою.

Готові реалізації для форку

• Референсна реалізація Infinitism (TypeScript) — створена авторами ERC-4337
• Stackup bundler (Go) — production bundler від Stackup
• Silius (Rust) — high-performance bundler (в 2 рази швидший за TypeScript-версію)
• Rundler (Rust) — bundler від Alchemy

Для кастомної розробки: TypeScript reference простіше для розуміння, Rust/Go краще для production throughput (до 3× більше UserOps за секунду).

Технологічний стек та терміни

Базовий centralized bundler з RPC, validation, mempool та bundle submission: 6-8 тижнів, від $15,000. Основна складність — коректний EVM tracer для storage access rules.

Production bundler з репутаційною системою, P2P mempool, MEV оптимізацією, моніторингом: 3-4 місяці, від $50,000.

Головне попередження: некоректна реалізація storage access rules веде або до прийняття небезпечних UserOps (DoS ризик), або до відхилення валідних (поганий UX). Ретельне тестування на всіх edge cases обов'язкове — ми маємо 98% успішних симуляцій після валідації.

Оцініть ваш проект безкоштовно: напишіть нам, і ми підготуємо пропозицію за 2 робочих дні. Замовте розробку custom bundler під ключ — ми реалізуємо його під вашу інфраструктуру. Зв'яжіться для консультації: допоможемо вибрати стратегію та розрахувати вартість.