Smart account Ethereum: UserOperation, bundler e sponsorizzazione del gas

Un account di proprietà esterna (EOA) dimostra il controllo con la firma di una chiave privata. Il suo nonce ordina le transazioni.

È un modello semplice, ma in genere la stessa chiave autorizza ogni azione e una normale transazione avvia di solito una sola chiamata di primo livello; il contratto chiamato può comunque attivarne altre al proprio interno.

La distinzione è utile accanto alla guida alle transazioni Ethereum in attesa, che descrive il pool delle transazioni EOA, non il percorso ERC-4337.

Uno smart account è un contratto che può detenere asset ed eseguire chiamate. Il suo codice di validazione può applicare regole specifiche dell’account: una firma, una soglia di più firme o permessi che scadono dopo un certo periodo.

ERC-4337 non stabilisce un unico prodotto wallet né una policy di recupero; offre un’interfaccia affinché un account contratto possa autorizzare ed eseguire operazioni.

La panoramica di Ethereum.org sull’account abstraction illustra possibilità come chiavi di riserva, permessi limitati e gas sponsorizzato, ma non tutti i wallet implementano ogni funzione.

L’etichetta «smart wallet» da sola non indica quanto sia sicuro un account né chi lo controlli.

Verifica quale contratto detiene gli asset, quali codice ed EntryPoint l’account considera affidabili e quali firmatari possono autorizzare le chiamate.

Se la logica dell’account è aggiornabile, anche i poteri amministrativi e le procedure di modifica incidono sul controllo degli asset.

Una UserOperation è un oggetto che descrive ciò che uno smart account vuole fare. In genere include l’account mittente, un nonce specifico dell’account, i dati della chiamata, una firma, limiti di gas e condizioni sulle commissioni.

Può includere anche le informazioni di una factory per creare un account o quelle di un paymaster per chiedere la sponsorizzazione. I campi esatti dipendono dalla versione di EntryPoint.

Invece di inviare direttamente l’oggetto alla chain con il metodo standard eth_sendTransaction, il wallet lo inoltra a un bundler o relay che espone metodi RPC ERC-4337 come eth_sendUserOperation.

La richiesta passa da un pool di UserOperation separato dal pool delle normali transazioni Ethereum. L’hash della UserOperation identifica la richiesta; la transazione on-chain creata dal bundler ha un hash e una ricevuta diversi.

ERC-7769 definisce i metodi RPC per invio, ricerca tramite hash e ricevute delle UserOperation.

La risposta di un bundler può indicare che la richiesta ha superato i controlli di quel servizio ed è entrata nel suo pool. Non dimostra che sia stata inclusa in un blocco o che l’azione dell’app sia riuscita.

Il modo in cui un bundler condivide la richiesta con altri dipende dalla sua infrastruttura e dalle sue policy. Distingui la conferma di un provider dal risultato registrato on-chain.

Il bundler riceve una UserOperation, ne verifica la compatibilità con la propria versione di EntryPoint e simula la logica di validazione dell’account e del paymaster.

Controlla la firma, la fiducia dell’account in quell’EntryPoint e la validità di nonce, gas e condizioni di sponsorizzazione. Può rifiutare un’operazione che viola le regole o non supera la simulazione.

La guida ERC-4337 ai bundler descrive la simulazione e l’invio di bundle.

Il bundler seleziona una o più operazioni valide e crea un’unica normale transazione Ethereum che chiama handleOps sull’EntryPoint.

L’inclusione della transazione in un blocco dipende comunque dalla produzione dei blocchi e dalle condizioni della rete. L’hash della UserOperation restituito non prova che l’esecuzione sia avvenuta sulla chain canonica.

Il pool delle UserOperation è distinto dal pool EOA: non dare per scontato che tutti i provider condividano le stesse richieste. Un bundler può rifiutare un’operazione o lasciarla in attesa.

Wallet e provider possono supportare chain, versioni di EntryPoint e policy diverse. Per verificarne lo stato, distingui la schermata del wallet, la ricevuta dell’operazione e quella on-chain della transazione bundle.

L’EntryPoint riceve la chiamata handleOps del bundler e invoca la funzione di validazione di ciascuno smart account. L’account verifica che la chiamata provenga da un EntryPoint attendibile e applica le proprie regole alla firma.

L’EntryPoint verifica e incrementa la sequenza di 64 bit per ogni account e chiave nonce; l’account può applicare logiche personalizzate al campo chiave di 192 bit. Così uno smart account può usare più chiavi, ciascuna con la propria sequenza.

Anche un paymaster opzionale controlla se sponsorerà l’operazione. Quando la validazione riesce, l’EntryPoint chiama la funzione di esecuzione dell’account per svolgere l’azione codificata in callData e regola il costo.

EntryPoint è il contratto centrale che consente flussi per smart account senza modificare il protocollo Ethereum per ciascun wallet. Verifica l’indirizzo effettivamente distribuito, la versione e le chain supportate dal wallet.

La guida ERC-4337 all’EntryPoint illustra più in dettaglio validazione ed esecuzione.

La simulazione è un’anteprima utile, non una garanzia di inclusione.

Stato della chain, commissioni, finestre di validità o stato di contratti esterni possono cambiare mentre l’operazione è in attesa e modificare il risultato della validazione on-chain.

Anche dopo la validazione una chiamata all’app può fallire o essere annullata. La sola inclusione in un blocco non prova che il trasferimento o l’azione prevista sia riuscita.

Se una UserOperation include informazioni sul paymaster, l’EntryPoint chiede a quel contratto se intende sponsorizzarla.

Un’app può così pagare le commissioni della transazione o permettere all’utente di iniziare senza tenere ETH nell’account.

Alcuni modelli consentono anche pagamenti in token o altri requisiti, a seconda del wallet e dell’implementazione del paymaster.

La sponsorizzazione non fa sparire il gas né elimina le condizioni. Un paymaster può limitare app, utenti, numero di operazioni o importi ammessi, esaminare la richiesta e rifiutarla.

Il suo deposito presso l’EntryPoint viene usato per pagare i costi delle operazioni. Se è richiesto uno stake separato, questo funge da garanzia secondo le regole di validazione: non è lo stesso fondo del deposito disponibile per il gas.

La guida ERC-4337 ai paymaster e EIP-4337 descrivono validazione e regolamento.

Una commissione pari a zero nell’interfaccia dell’app non significa costo inesistente. Lo sponsor può pagare prima e recuperare valore in seguito tramite abbonamento, pagamento in token o condizioni del servizio.

Verifica chi sostiene alla fine il costo, se la sponsorizzazione ha un tetto o un limite d’uso e se un’operazione fallita può comunque comportare commissioni.

Se il wallet lo supporta, l’utente può inserire l’autorizzazione di un’app e uno swap nella stessa UserOperation. Le due azioni vengono inviate come un’unica operazione tramite EntryPoint.

È diverso sia da una normale transazione EOA sia dal bundler che riunisce più UserOperation distinte in una transazione on-chain. Controlla l’anteprima del wallet per capire quale struttura viene usata.

Facciamo un esempio ipotetico: supponiamo che un’operazione sponsorizzata e approvata abbia un costo effettivo di gas pari a 0,0012 ETH.

Il costo potrebbe essere regolato dal deposito del paymaster presso l’EntryPoint anziché dal saldo dell’utente. 0,0012 ETH è un dato illustrativo, non un prezzo o preventivo attuale.

L’importo reale dipende dal gas usato, dalle condizioni di commissione e dalla rete.

Il batching non è automaticamente più economico o sicuro. L’atomicità di più chiamate dipende da come lo smart account gestisce gli errori.

Verifica se il fallimento di una chiamata annulla l’intero batch, se alcune azioni possono restare completate e chi paga il gas. Una stima errata o un’app non disponibile può causare un rifiuto o un errore di esecuzione.

La guida alle commissioni del gas Ethereum spiega i campi generali delle commissioni.

Uno smart account può prevedere firmatari di riserva o una procedura di recupero in cui guardiani fidati raggiungono una soglia per sostituire una chiave.

Alcuni progetti aggiungono un periodo di attesa durante il quale la chiave esistente può opporsi. Se però è sempre necessaria una sola firma, la perdita di quella chiave può lasciare senza recupero.

ERC-4337 permette agli account di validare secondo le proprie regole; non fornisce per impostazione predefinita chiavi di riserva o recupero sociale a tutti.

Pochi guardiani o regole deboli di sostituzione delle chiavi possono aprire una via d’attacco. Troppi guardiani o requisiti gravosi possono ritardare il recupero legittimo del proprietario.

Controlla la soglia, il periodo di attesa, i diritti di annullamento e come sono protette le chiavi di recupero. Queste regole stabiliscono anche chi può bloccare un’operazione, non solo chi può autorizzarla.

Un wallet a contratto non è automaticamente custodial o non custodial.

Il controllo dipende da chi detiene le chiavi di firma, dalla presenza di poteri di amministrazione o aggiornamento e da ciò che un firmatario ospitato o un servizio di recupero può autorizzare.

Esamina separatamente il contratto che detiene gli asset e le chiavi o i servizi che lo controllano.

Il backup della seed phrase tradizionale è un tema distinto trattato nella guida al recupero del wallet.

Nell’anteprima del wallet verifica rete, indirizzo dell’account, contratti destinatari, dati della chiamata, ambito delle approvazioni dei token e numero di chiamate.

Una firma può autorizzare più dell’azione singola evidenziata nell’interfaccia. Se non capisci i dati firmati, consulta la documentazione ufficiale dell’app e del wallet prima di procedere.

Per capire la sponsorizzazione, leggi criteri di ammissibilità, limiti d’uso, modalità di pagamento alternative e regole sui costi in caso di errore; non affidarti solo al nome del paymaster.

Un’etichetta di sponsorizzazione attiva non significa che l’app sia sempre gratuita e il paymaster può ancora rifiutare l’operazione. Congestione della rete e ritardi nell’inclusione restano problemi distinti.

Se una UserOperation resta in attesa a lungo, non applicare senza controlli la procedura EOA «accelera» o «annulla»: verifica prima come il wallet gestisce le UserOperation. Cerca l’hash dell’operazione e la relativa ricevuta.

Se è disponibile l’hash della transazione del bundler, controlla anche la ricevuta del blocco e l’esito dell’esecuzione. Le ricevute RPC possono distinguere costo ed esito di una singola operazione dalla ricevuta dell’intero bundle.

Questo è diverso dalla sostituzione o dall’annullamento di una transazione EOA con lo stesso nonce.