Bundler e UserOperation: come funzionano le transazioni ERC-4337

Una UserOperation è l'oggetto di intento firmato definito da ERC-4337: dichiara cosa un account a smart contract vuole fare e come quell'azione debba essere validata e pagata. A differenza di una normale transazione Ethereum non è un oggetto a livello di protocollo firmato da un account externally owned: la sua firma viene verificata dal contratto dell'account stesso, e non è tenuta a pagare da sola il proprio gas nativo. Un bundler è l'attore off-chain che raccoglie le UserOperation da una mempool alternativa dedicata, simula ciascuna di esse, impacchetta quelle valide in una singola normale transazione Ethereum e chiama il contratto canonico EntryPoint — che valida ogni operazione del batch prima di eseguirne una qualsiasi. Il bundler anticipa il gas reale dal proprio EOA e viene rimborsato on-chain dall'account mittente o dal paymaster di quell'account. Un contratto paymaster opzionale può accettare di coprire un'operazione durante quel passaggio di validazione, ed è lì che le commissioni diventano sponsorizzate oppure pagabili in un token ERC-20 anziché nel token di gas nativo della chain.

Un rapido riepilogo su ERC-4337

ERC-4337 è lo standard Ethereum per l'account abstraction — un modo per dare agli account a smart contract la stessa capacità di primo piano di avviare e pagare azioni che gli account externally owned (EOA) hanno sempre avuto, senza alcuna modifica al protocollo di base. Invece di modificare il livello di consenso, ERC-4337 introduce un sistema parallelo di oggetti di livello più alto e di infrastruttura off-chain che alla fine viene saldato tramite normali transazioni Ethereum. Se prima vuoi la versione dalle fondamenta, l'approfondimento su cos'è l'account abstraction copre le motivazioni, cos'è ERC-4337 mappa l'intero standard e smart account vs EOA mette a confronto direttamente i due tipi di account. Questo articolo si concentra sulla meccanica: gli oggetti che si muovono nel sistema e gli attori che li elaborano. Nota che ERC-4337 è uno standard EVM — si applica a Ethereum e alle chain compatibili EVM, non alle chain non-EVM come Solana o TON.

Cos'è davvero una UserOperation

L'oggetto centrale in ERC-4337 è la UserOperation. A prima vista sembra una transazione, ma si comprende meglio come una dichiarazione firmata di intento: "ecco cosa vuole fare il mio account, ed ecco i parametri per validarlo e pagarlo." È una struct passata come calldata a un contratto, non un oggetto nativo del protocollo — il livello base non ne ha mai sentito parlare.

In sostanza, una UserOperation contiene:

• sender — l'account a smart contract per conto del quale agisce l'operazione.
• nonce — protezione dal replay, tracciata dall'EntryPoint come valore in due parti (una chiave più una sequenza), così che un account possa gestire diverse corsie di nonce indipendenti anziché un'unica coda rigida.
• callData — ciò che l'account deve eseguire, spesso un batch di più chiamate in un'unica operazione.
• dati di deployment dell'account — opzionali; effettuano il deploy del contratto dell'account alla sua primissima operazione, ed è così che uno smart account può essere finanziato a un indirizzo noto, derivato in modo deterministico, prima ancora di esistere on-chain.
• limiti di gas — budget separati per validazione ed esecuzione, più un valore preVerificationGas che compensa il bundler per i calldata e per l'overhead che l'EntryPoint non può misurare da sé.
• parametri della commissione — una commissione massima e una priority fee massima, sul modello di EIP-1559.
• dati del paymaster — opzionali; quale contratto sponsorizzerà l'operazione e il contesto di cui ha bisogno.
• firma — verificata dalla funzione di validazione dell'account stesso, non dal protocollo.

La codifica esatta è cambiata tra le versioni dell'EntryPoint — la v0.7 separa i blob di deployment e di paymaster in campi espliciti e comprime insieme diversi valori di gas, mentre la v0.6 usava singole stringhe di byte initCode e paymasterAndData — ma il contenuto concettuale è lo stesso. Se stai facendo un'integrazione, verifica quale versione dell'EntryPoint prende di mira il tuo bundler.

La differenza chiave rispetto a una transazione normale è chi e cosa la firma. Una transazione Ethereum convenzionale deve essere firmata dalla chiave privata di un EOA con uno schema ECDSA fisso, e lo stesso account paga il gas. Una UserOperation è validata dalla logica dell'account a smart contract del mittente — che può implementare qualsiasi schema di firma, regola multi-chiave, session key o policy di autorizzazione l'account definisca — e non deve necessariamente pagarsi da sola in gas nativo. Questa flessibilità è tutto il punto: è l'account, non il protocollo, a decidere cosa sia un'azione valida.

La mempool alternativa in cui vivono

Le UserOperation non entrano nella normale mempool delle transazioni Ethereum, perché non sono ancora transazioni. Vengono invece trasmesse a una mempool alternativa separata (spesso chiamata alt-mempool) — una rete peer-to-peer dedicata agli oggetti ERC-4337. In pratica un wallet o una dApp ne invia una chiamando eth_sendUserOperation sull'endpoint RPC di un bundler; quel bundler può poi propagarla nell'alt-mempool condivisa oppure tenerla in un proprio pool privato. In entrambi i casi, l'infrastruttura che consuma questi oggetti resta in ascolto qui anziché sulla mempool del livello base. Questa separazione tiene il traffico di account abstraction fuori dal percorso critico per il consenso fino al momento in cui viene impacchettato in una vera transazione.

Il ruolo del bundler

Un bundler è l'attore off-chain che trasforma gli intenti in realtà on-chain. Il suo compito ha quattro parti. Primo, raccoglie le UserOperation dalla mempool alternativa. Secondo, simula e valida ciascuna — eseguendo la logica di validazione dell'account in un contesto simulato per confermare che la firma sia valida, il nonce corretto e che l'account o il suo paymaster possa coprire il costo. Terzo, impacchetta una o più UserOperation valide in una singola normale transazione Ethereum. Quarto, invia quella transazione alla rete dal proprio EOA, pagando in anticipo il gas del livello base e aspettandosi di essere rimborsato on-chain.

La sola simulazione non basta come protezione, perché lo stato può cambiare tra la simulazione e l'inclusione. Per questo ERC-4337 limita anche ciò che il codice di validazione ha il permesso di fare: durante la fase di validazione un account o un paymaster non può leggere il timestamp dei blocchi o altri valori d'ambiente che gli consentirebbero di comportarsi on-chain diversamente da come si comporta in simulazione, e il suo accesso allo storage è in larga parte limitato agli slot associati al proprio account. Ai contratti che agiscono per conto di molti utenti — in particolare factory e paymaster — si chiede di depositare uno stake, così che un singolo contratto che si comporta male non possa invalidare a poco prezzo una grossa fetta della mempool tutta in una volta. Queste regole esistono per un motivo solo: rendere la simulazione di un bundler una previsione affidabile di ciò che accadrà on-chain.

Poiché il bundler anticipa il gas e guadagna commissioni per l'inclusione, si comporta molto come un block builder specializzato per il traffico di account abstraction. Il suo passaggio di simulazione-e-validazione è ciò che lo protegge: non impacchetterà un'operazione che non riuscirebbe a rimborsarlo.

Il contratto EntryPoint

Tutto converge su un singolo, canonico smart contract chiamato EntryPoint. È un singleton, distribuito per ogni versione allo stesso indirizzo su tutte le chain EVM, e custodisce i depositi con cui vengono pagate le operazioni. La transazione del bundler è una chiamata all'EntryPoint con un array di UserOperation, e l'EntryPoint esegue poi un rigoroso ciclo in due fasi.

Nella fase di validazione, per ogni operazione chiama la funzione di validazione dell'account mittente (e quella del paymaster, se ne è specificato uno) per ri-verificare on-chain la firma, il nonce e l'accordo di pagamento, e riserva il costo massimo possibile a carico di chi paga. Solo dopo che tutte le operazioni del batch sono state validate passa alla fase di esecuzione, in cui invia i calldata di ciascuna operazione al rispettivo account per eseguire effettivamente il trasferimento, lo swap o l'altra azione, per poi saldare il costo reale e rimborsare la riserva non utilizzata.

Questa separazione è importante: validazione ed esecuzione sono divise in modo che le garanzie di pagamento di un batch siano stabilite prima che venga eseguito qualsiasi lavoro che modifica lo stato, e così l'EntryPoint può contabilizzare il gas con precisione su molte operazioni in una volta sola. Significa anche che il fallimento di un'operazione durante l'esecuzione non può contaminare le altre del batch.

Dove si colloca il paymaster

Un paymaster è un contratto opzionale che accetta di pagare una UserOperation per conto dell'account. Quando una UserOperation include dati di paymaster, l'EntryPoint chiede a quel paymaster, durante la fase di validazione, se sponsorizzerà l'operazione e a quali condizioni; il paymaster restituisce una decisione più un blob di contesto. Dopo l'esecuzione l'EntryPoint richiama il paymaster in un passaggio post-operazione comunicando il gas effettivamente consumato, ed è lì che un paymaster che addebita in token salda l'importo esatto. Il paymaster può accettare incondizionatamente (vera sponsorizzazione gasless, in cui è un'app ad assorbire il costo), oppure può accettare in cambio di valore — più utilmente, addebitando all'utente un token ERC-20 invece del gas nativo. Per uno sguardo più approfondito a questo componente, vedi cos'è un paymaster. Il paymaster è il punto di aggancio del flusso che disaccoppia "con cosa paga l'utente" da "con cosa viene pagata la rete."

Come vengono gestiti gas e fallimenti

Il gas in ERC-4337 è stratificato. Il bundler paga vero ETH per la transazione esterna; l'EntryPoint misura il gas di validazione ed esecuzione di ogni UserOperation rispetto ai limiti dichiarati; e chiunque sia responsabile — l'account o il suo paymaster — deve aver depositato abbastanza presso l'EntryPoint per coprire il conto, che viene saldato alla fine del batch. Una conseguenza da tenere presente: un'operazione ERC-4337 costa un po' più gas della transazione semplice equivalente, perché oltre all'azione in sé stai pagando la validazione a livello di contratto e la contabilità dell'EntryPoint.

I fallimenti sono contenuti dal design validazione-prima-di-tutto. Se un'operazione fallisce durante la validazione on-chain, l'intero batch andrebbe in revert: perciò il bundler la scarta e ricompone il pacchetto invece di lasciare che accada — ed è esattamente a questo che serve la sua simulazione off-chain. Se un'operazione supera la validazione ma la sua esecuzione fa revert, gli effetti dell'esecuzione vengono annullati mentre il gas già speso viene comunque contabilizzato e pagato, così il bundler non resta senza compenso per un lavoro onesto. Questa asimmetria è il motivo per cui i bundler simulano con tanta attenzione: la loro protezione contro il grief è rifiutare di includere qualsiasi cosa che non li rimborserebbe.

Il ciclo di vita, in ordine

1. Il tuo wallet costruisce una UserOperation: sender, nonce, calldata, limiti di gas, parametri della commissione, dati opzionali del paymaster.
2. Un paymaster, se usato, approva le condizioni di sponsorizzazione prima che l'operazione venga trasmessa.
3. La logica di firma del tuo account la firma — e non deve necessariamente essere una singola chiave ECDSA.
4. Il wallet la invia all'RPC di un bundler, ed entra nella mempool alternativa.
5. Il bundler la simula e la valida secondo le regole dello standard su opcode limitati e accesso allo storage.
6. Il bundler la impacchetta con altre operazioni in un'unica transazione Ethereum che chiama handleOps sull'EntryPoint, e paga il gas del livello base.
7. L'EntryPoint valida ogni operazione, esegue i calldata di ciascuna, salda i costi a valere sui depositi, rimborsa l'eccedenza e risarcisce il bundler.

Cosa ne ricava chi usa un wallet

Il macchinario è elaborato, ma il suo scopo è concreto e utile: raggruppare più azioni in un'unica conferma (approve e swap insieme, per esempio), commissioni sponsorizzate o pagate in token, schemi di firma diversi da una singola chiave secp256k1, policy di spesa e session key, e recupero social o basato sul dispositivo. Vale la pena notare che EIP-7702 permette a un normale EOA di eseguire temporaneamente con codice da smart account, il che riduce il divario per alcune di queste funzionalità senza sostituire l'infrastruttura ERC-4337 descritta sopra.

Come WATS utilizza tutto questo

Sulle chain EVM, WATS si affida esattamente a un pezzo di questo flusso: lo slot del paymaster. Quando effettui un trasferimento, uno swap o uno stake nel WATS Hot Wallet, la UserOperation costruita dal tuo wallet indica un paymaster, ed è quel paymaster a consentire che la commissione venga addebitata in ATS anziché nel token di gas nativo della chain — così non devi mai tenere un residuo di ETH, BNB o POL su ogni rete solo per poter operare. Non ti viene chiesto di gestire un bundler, di scegliere una versione dell'EntryPoint o di procurarti una chiave RPC di un bundler: quella è infrastruttura, e il compito del wallet è costruire una UserOperation valida e inviarla.

Due precisazioni per restare onesti. Primo, pagare in ATS non è uno sconto — la rete continua ad addebitare la sua commissione normale e il paymaster la salda, quindi ciò che cambia è quale token esce dal tuo saldo, non il costo sottostante. Secondo, ERC-4337 esiste solo su EVM, quindi su Solana e TON è un accordo di fee-payer equivalente a svolgere il ruolo del paymaster, non il flusso EntryPoint descritto qui. ATS è un OFT di LayerZero, ed è questo che consente a un unico saldo ATS di coprire le commissioni su Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana e TON; gli ATS incassati vengono bruciati, portando l'offerta da 100.000.000 fino a un floor di 30.000.000. WATS resta pienamente non-custodial dall'inizio alla fine: le chiavi le detieni tu, e WATS non ne detiene mai nessuna.

Se vuoi vedere questo flusso come un sistema funzionante e non come una specifica, il passo concreto è provare un trasferimento nel WATS Hot Wallet su una chain in cui non possiedi il token di gas nativo: la UserOperation, il bundler e l'EntryPoint fanno il loro lavoro fuori scena, e la commissione esce dal tuo saldo ATS. Come funziona il modello di commissioni ATS spiega la meccanica dall'inizio alla fine.