EIP-7702: delega del codice EOA e rischi

Una EOA tradizionale firma transazioni con una chiave privata e non ha codice eseguibile al proprio indirizzo. EIP-7702 permette all’account di puntare a codice già distribuito altrove. Quando un’operazione raggiunge l’account delegato, il client carica il codice di destinazione e lo esegue nel contesto dell’account. Il codice risiede a un altro indirizzo, ma indirizzo, saldo e contesto di archiviazione appartengono all’account delegante.

Non è un trasferimento a un nuovo indirizzo di contratto né la sostituzione della chiave privata. L’indirizzo e la chiave originali rimangono. Un indicatore di delega valido consente ancora alla EOA di avviare normali transazioni. Cambia il percorso di esecuzione delle chiamate; lo standard non divide automaticamente una chiave in ruoli più sicuri.

La specifica EIP-7702 definisce una transazione set-code di tipo 4 e una lista di autorizzazioni. Anche la guida Pectra di Ethereum.org la descrive come un puntatore a codice già distribuito. L’etichetta «account intelligente» di un wallet non rivela regole di convalida, recupero o codice delegato effettivi.

Distingui chi conserva la chiave privata da chi ha distribuito o controlla il codice delegato. Verifica se il codice può essere modificato, chi può aggiornarlo e quali effetti può avere su asset e archiviazione dell’account. L’EIP non risponde da solo a queste domande di sicurezza.

La transazione set-code è identificata dal byte di tipo 0x04. Ai campi consueti della transazione esterna aggiunge una lista di autorizzazioni. Ogni tupla contiene un ID di chain, un indirizzo di codice, il nonce dell’account autorizzante e la firma che approva la tupla. L’autorità firma l’autorizzazione; il mittente firma separatamente la transazione esterna. I due ruoli possono coincidere oppure appartenere a account diversi.

Poiché un mittente può includere l’autorizzazione valida di un’altra persona, controlla cosa approva esattamente l’account autorizzante. L’ID di chain normalmente limita l’autorizzazione a una chain; il valore 0 consente un ambito più ampio sulle chain compatibili. Non significa che la stessa autorizzazione avrà successo ovunque: la chain deve supportare EIP-7702 e nonce e stato dell’account devono corrispondere. Un ambito ampio può però esporre la firma a un uso su un’altra chain supportata.

Una tupla può essere ignorata se il nonce non corrisponde o fallisce un’altra verifica. Un carattere sbagliato nell’indirizzo di destinazione può indicare un codice diverso. Confronta rete, account e indirizzo completo nella schermata di firma e in un block explorer affidabile. Un messaggio vago come «aggiornamento» o «risparmio gas» non identifica il permesso concesso.

La documentazione delle transazioni di Ethereum.org descrive le transazioni di tipo 4 come contenenti una lista di autorizzazioni. La transazione esterna conserva condizioni di gas e un soggetto che paga la commissione: l’invio da un altro indirizzo non rende l’esecuzione gratuita. Il tipo 4 è distinto anche dalle UserOperation e dai paymaster ERC-4337, descritti nella guida agli smart account.

Dopo un’autorizzazione valida, il codice EOA riceve un indicatore formato dal prefisso 0xef0100 e dall’indirizzo di destinazione. Il client riconosce l’indicatore e carica il codice di tale indirizzo durante l’esecuzione. L’indirizzo dell’account mostrato nel wallet può quindi differire da quello del codice in esecuzione. Controllali entrambi.

Il codice viene caricato dalla chain corrente su cui si usa la delega. Un indirizzo di destinazione su un’altra rete non fa eseguire qui il codice di quella rete. Lo stesso indirizzo di 20 byte può avere codice diverso, o nessun codice, su chain differenti. Verifica distribuzione e sorgente verificata su ogni chain; non affidarti solo a nomi, icone o indirizzi uguali.

Il codice delegato viene eseguito nel contesto dell’account autorizzante e può usare la sua archiviazione. A seconda della logica può inviare ETH o token, chiamare contratti esterni e modificare valori archiviati. EIP-7702 non aggiunge automaticamente regole come «solo questo token» o «una chiamata al giorno». Eventuali limiti devono essere implementati e applicati correttamente dal sistema delegato.

Se la destinazione è un proxy o può essere aggiornata, il codice controllato oggi potrebbe non essere lo stesso in seguito. Verifica amministratori, permessi di sostituzione dell’implementazione, ritardi e procedura pubblica di aggiornamento. Un’autorità di aggiornamento sconosciuta resta un rischio finché la delega è attiva.

Il protocollo non confina automaticamente il codice delegato a un insieme ristretto di permessi. Un controllo difettoso può consentire trasferimenti di asset, autorizzazioni di token, chiamate esterne arbitrarie o modifiche all’archiviazione. Un bollino di audit non dimostra che indirizzo e versione richiesti coincidano con codice e ambito verificati.

Le considerazioni di sicurezza dell’EIP avvertono che la logica delegata potrebbe dover legare alla firma protezione dai replay, destinazione e dati di chiamata, valore ETH e condizioni del gas. Se mancano campi importanti, uno sponsor o un’altra parte può inviare una richiesta diversa dall’intenzione del firmatario oppure provocare un fallimento. Controlla quali chiamate il codice convalida e se un chiamante esterno può aggirare le verifiche.

Per esempio, un wallet può raggruppare l’approvazione di un token e uno scambio in una sola conferma. Verifica se le due operazioni falliscono insieme, se l’approvazione è limitata all’importo necessario e se può poi essere ridotta. Se un paymaster copre le commissioni, controlla chi paga e a quali condizioni. Leggi l’anteprima completa perché l’etichetta «gratis» non nasconda chiamate o permessi autorizzati.

La sicurezza dipende dai permessi reali e dal controllo degli aggiornamenti, non solo dalla reputazione della destinazione. Verifica quali contratti può chiamare l’account, come vengono convalidate le firme, chi detiene poteri di emergenza o aggiornamento e se il codice distribuito corrisponde alla sorgente verificata. Se l’indirizzo è sconosciuto o arriva da un messaggio non richiesto, fermati e consulta la documentazione ufficiale del wallet.

EIP-7702 elabora la lista di autorizzazioni prima dell’esecuzione della transazione esterna. La specifica afferma che gli indicatori di delega già elaborati non vengono annullati se l’esecuzione successiva fallisce o fa revert. Non presumere che l’intero stato torni com’era solo perché la ricevuta segnala un fallimento. Controlla separatamente ricevuta e codice attuale dell’account.

È importante per chiamate raggruppate, inizializzazione e transazioni inviate da uno sponsor. L’autorizzazione può essere valida ma una chiamata successiva può fallire: la delega può restare attiva anche se configurazione o azione attesa non si è completata. Se la tupla stessa non era valida, può non essere stata applicata. Controlla transazione di tipo 4, account autorizzante, nonce e puntatore al codice attuale invece di affidarti a una sola etichetta di esito.

Lo stato «fallito» del wallet può riassumere un errore nella verifica dell’autorizzazione, una chiamata esterna o un altro passaggio. Se il risultato non è chiaro, confronta hash della transazione, autorità e nonce firmati e codice dell’account con uno strumento di chain affidabile. Un nuovo tentativo può incontrare un nonce cambiato e rendere inutilizzabile la firma precedente; verifica prima eventuali invii duplicati o già elaborati.

La distinzione conta quando ci si aspetta che ogni parte di una conferma venga annullata insieme. Provare la funzione con un account di test o di valore ridotto aiuta a osservarne il comportamento, ma non prova la sicurezza del codice. Prima di usare un account finanziato, assicurati di poter verificare ambito chain, destinazione, dati di chiamata e stato residuo dopo un fallimento.

Una nuova autorizzazione può indicare codice diverso. L’EIP definisce anche la cancellazione dell’indicatore autorizzando l’indirizzo nullo, così che il codice dell’account torni vuoto. L’operazione rimuove l’indicatore di delega; non è un comando universale di pulizia o recupero.

Se il codice delegato ha scritto valori nell’archiviazione dell’account, rimuovere l’indicatore non li cancella automaticamente. Anche un’autorizzazione token registrata da un contratto ERC-20 è separata dal codice dell’account. Un’autorizzazione illimitata precedente potrebbe dover essere revocata sul contratto del token. Cancellare la delega non annulla token già inviati, modifiche a contratti esterni o transazioni completate.

Il nuovo codice può riutilizzare la stessa archiviazione: versioni che interpretano diversamente le stesse posizioni possono entrare in conflitto. Verifica layout e piano di migrazione prima di cambiare. Senza compatibilità, l’account può bloccarsi o lo stato precedente può comportarsi in modo inatteso; il protocollo non offre un azzeramento generale dell’archiviazione al cambio del puntatore.

Scegli la risposta in base al problema. Se il codice può essere dannoso, valuta rapidamente un flusso di cancellazione supportato dal wallet o una sostituzione affidabile. Per le autorizzazioni token, consulta la guida separata su approvazioni e allowance dei token. Se la chiave o la frase seed è esposta, cancellare il codice non recupera la chiave: segui la guida al recupero del wallet e valuta di spostare i fondi in un account sicuro.

Per prima cosa verifica nella documentazione ufficiale del wallet che supporti EIP-7702 sulla rete scelta. Confronta rete e ID chain, account, indirizzo esatto di destinazione, codice verificato e ogni amministratore di proxy o aggiornamento. Comprendi se l’ID 0 estende l’ambito ad altre chain o se la firma è limitata a una sola. Se la schermata è poco chiara, consulta la documentazione del wallet prima di approvare.

Poi distingui firma di autorizzazione, mittente della transazione esterna e pagatore della commissione. Un mittente diverso non modifica ciò che l’autorità ha firmato. La sponsorizzazione non rende sicuro il codice né lo limita alle chiamate previste. Confronta tipo, lista di autorizzazioni, destinatari, dati di chiamata e modifiche agli allowance con l’anteprima.

Se una delega è già attiva, non controllare solo se la transazione è riuscita. Ispeziona l’indicatore attuale e l’indirizzo del codice. Se differiscono da quanto previsto, sospendi ulteriori chiamate e approvazioni ed evita autorizzazioni casuali ripetute. Per le commissioni della transazione esterna consulta la guida alle commissioni gas di Ethereum; per nonce e transazioni EOA in attesa la guida alle transazioni in sospeso.

EIP-7702 standardizza un formato di transazione che collega una EOA a codice distribuito. Raggruppamento, commissioni sponsorizzate, permessi di sessione e recupero possono essere costruiti sopra il meccanismo, ma dipendono da codice e servizi specifici. Wallet e deleghe diversi non applicano necessariamente le stesse regole o funzionalità.

La scritta «account intelligente» non dice chi detiene la chiave, chi può aggiornare il codice o chi modifica il recupero. Verifica implementazione e impostazioni reali. Se il wallet non supporta la chain o la funzione, può mostrare lo stato della delega in modo diverso dal previsto. Controlla la compatibilità prima di modificare un account finanziato.

L’annuncio Pectra mainnet della Ethereum Foundation descrive le EOA che puntano a codice delegato e la possibilità di sostituire o revocare l’autorizzazione. Le capacità dello standard e il modo in cui un wallet le mostra agli utenti sono questioni distinte. UserOperation e paymaster ERC-4337 sono un altro percorso di astrazione account, non l’autorizzazione di tipo 4.

Questa guida spiega la meccanica degli account e non consiglia un wallet o delegato specifico. Definisci prima l’obiettivo — raggruppare chiamate, sponsorizzare commissioni, permessi di sessione o recupero — poi individua codice e servizio che lo realizzano e il livello di fiducia richiesto. La guida agli smart account e a ERC-4337 tratta meccanismi correlati.