ERC-4337: pagamento delle commissioni da parte di terzi, operazioni raggruppate e regole di spesa. Cosa funziona già e cosa resta sulla carta oggi.
Un nuovo utente scarica un portafoglio digitale, genera una frase di recupero che non capisce fino in fondo, e alla prima transazione scopre che deve possedere già una piccola somma della valuta nativa della rete solo per pagare la commissione, prima ancora di poter fare qualunque altra cosa. È uno degli ostacoli più citati per chi si avvicina per la prima volta a questo tipo di strumenti, e ERC-4337 è la proposta tecnica pensata per eliminarlo, insieme a molti altri limiti strutturali degli account tradizionali.
Lo standard descrive un modo per far funzionare i portafogli come contratti programmabili invece che come semplici coppie di chiavi, aprendo la porta a funzionalità che gli account tradizionali non hanno mai potuto offrire nativamente: qualcuno che paga la commissione al posto tuo, transazioni multiple eseguite come un’unica operazione, regole di spesa che limitano automaticamente che cosa un dispositivo compromesso potrebbe fare.
Questo testo distingue con precisione che cosa di questa proposta è già utilizzabile in pratica oggi, con applicazioni reali attive, e che cosa resta invece un obiettivo dichiarato ma non ancora pienamente realizzato nella maggior parte dei portafogli in circolazione.
Il quadro in sintesi
- Il pagamento delle commissioni da terzi funziona già. Diversi portafogli lo offrono come funzionalità attiva.
- Le operazioni raggruppate sono la funzionalità più matura. Molte applicazioni la usano per semplificare interazioni complesse.
- Le regole di spesa programmabili sono parziali. Alcune esistono, altre restano più ambiziose che implementate.
- L’adozione varia molto per rete. Alcune reti hanno un’infrastruttura di supporto matura, altre quasi nulla.
- Non richiede di cambiare la rete sottostante. Funziona come livello aggiuntivo sopra l’infrastruttura esistente.
Che cosa cambia rispetto a un portafoglio tradizionale
Un account tradizionale su queste reti è governato da una sola regola rigida: chi possiede la chiave privata corrispondente può autorizzare qualunque operazione, senza eccezioni né condizioni intermedie. Non esiste un modo nativo per dire che un account può spendere solo fino a una certa soglia al giorno, o che un’operazione richiede l’approvazione di due dispositivi diversi, se non ricorrendo a soluzioni esterne costruite sopra questa regola di base.
ERC-4337 propone di sostituire questa logica rigida con un account che è, a tutti gli effetti, un contratto programmabile: le regole che determinano quando e come una transazione viene autorizzata possono essere scritte nel codice dell’account stesso, invece di dipendere unicamente dal possesso di una singola chiave privata.
Questa differenza concettuale è la stessa che separa già oggi un portafoglio a calcolo multipartitico da uno a firma singola, con la differenza che ERC-4337 non richiede una tecnologia crittografica specifica per la gestione delle chiavi: definisce piuttosto un formato standard che permette a qualunque logica di autorizzazione, incluse quelle basate su più firme o su calcolo multipartitico, di funzionare in modo compatibile con l’infrastruttura di rete esistente.
Il pagamento delle commissioni da parte di terzi
La funzionalità più immediatamente comprensibile, e anche una delle più mature nell’adozione pratica, riguarda la possibilità che un soggetto diverso dal titolare dell’account paghi la commissione di rete per una transazione. Un’applicazione può decidere di coprire questo costo per i propri utenti, eliminando la necessità che un nuovo utente possieda già fondi nella valuta nativa della rete solo per compiere la sua prima operazione.
Il soggetto che rende possibile questo meccanismo si chiama paymaster, un contratto che accetta di coprire la commissione secondo condizioni che l’applicazione stessa definisce, per esempio limitando il beneficio a un numero massimo di transazioni per nuovo utente, o accettando il pagamento in una valuta diversa da quella nativa della rete, convertendola internamente al momento dell’esecuzione.
Questa funzionalità è oggi effettivamente in uso in diverse applicazioni pensate per un pubblico che non ha familiarità con la gestione di più valute diverse solo per pagare le commissioni di rete, ed è probabilmente il fattore che ha contribuito di più, fra tutti quelli descritti in questo testo, a ridurre concretamente l’attrito per chi si avvicina per la prima volta a questi strumenti.
Le operazioni raggruppate
Una seconda funzionalità, altrettanto matura nell’adozione pratica, permette di raggruppare più operazioni distinte in un’unica transazione eseguita atomicamente: o tutte le operazioni incluse nel gruppo vengono eseguite con successo, o nessuna di esse produce effetto, eliminando gli stati intermedi problematici che si verificano quando un’operazione multi-passaggio si interrompe a metà.
Un esempio pratico riguarda l’interazione con un contratto che richiede prima un’autorizzazione di spesa e poi l’esecuzione dell’operazione vera e propria: con un account tradizionale, queste sono due transazioni separate, ciascuna con la propria commissione e il proprio momento di conferma, con il rischio che la seconda fallisca dopo che la prima è già stata confermata. Con le operazioni raggruppate, l’intera sequenza diventa una singola transazione, più semplice da gestire e generalmente più economica in termini di commissioni complessive.
Questa funzionalità semplifica anche l’interazione con gli strumenti descritti a proposito della revoca delle approvazioni concesse a un contratto, permettendo di revocare più autorizzazioni in un’unica operazione invece che una alla volta, riducendo sia il tempo necessario sia il costo complessivo dell’operazione di pulizia periodica.
Le regole di spesa programmabili
La funzionalità più ambiziosa, e quella con il divario più ampio fra la promessa teorica e l’implementazione effettivamente disponibile oggi, riguarda le regole di spesa programmabili: la possibilità di configurare un account in modo che rifiuti automaticamente operazioni che superano una soglia definita, o che richieda un’approvazione aggiuntiva per trasferimenti verso indirizzi non precedentemente autorizzati.
Alcuni portafogli offrono già versioni semplificate di questa funzionalità, come un limite giornaliero di spesa configurabile dall’utente, superato il quale l’operazione richiede un passaggio di conferma aggiuntivo. Versioni più sofisticate, come regole che si adattano al comportamento storico dell’account per segnalare operazioni anomale, restano in gran parte allo stadio sperimentale o disponibili solo in implementazioni specifiche non ancora diffuse su larga scala.
Il divario fra la teoria e la pratica in quest’area dipende in parte dalla complessità stessa del problema: definire regole di spesa che proteggano efficacemente senza risultare talmente restrittive da rendere il portafoglio scomodo nell’uso quotidiano richiede un equilibrio che gli sviluppatori stanno ancora affinando, sulla base dell’esperienza raccolta dalle prime implementazioni messe in produzione.
Un ulteriore ostacolo pratico riguarda la revisione del codice che implementa queste regole: un account programmabile con una logica di spesa complessa introduce una superficie di attacco che un account tradizionale, con la sua unica regola rigida, semplicemente non possiede. Un errore nella scrittura di queste regole può, in casi estremi, produrre l’effetto opposto a quello desiderato, bloccando operazioni legittime o, peggio, autorizzandone di indesiderate a causa di una condizione mal definita nel codice.
Il recupero dell’account senza una singola frase mnemonica
Una conseguenza diretta della programmabilità degli account riguarda il recupero in caso di perdita dell’accesso: invece di dipendere esclusivamente da una frase mnemonica che, se persa, rende l’account irraggiungibile per sempre, un account programmabile può implementare schemi di recupero alternativi, come l’approvazione di un insieme di contatti fidati designati in anticipo dal titolare.
Questo approccio condivide il principio di fondo con quanto già descritto a proposito del funzionamento delle firme di autorizzazione, applicato però al recupero dell’intero account piuttosto che all’autorizzazione di singole operazioni, e rappresenta uno dei cambiamenti più significativi rispetto al modello di sicurezza tradizionale basato interamente sul segreto di una singola frase.
La tabella di ciò che funziona oggi
| Funzionalità | Stato di adozione | Dove è più diffusa |
|---|---|---|
| Pagamento commissioni da terzi | Ampiamente disponibile | Applicazioni orientate a nuovi utenti |
| Operazioni raggruppate | Ampiamente disponibile | Interazioni con contratti complessi |
| Limiti di spesa semplici | Parzialmente disponibile | Alcuni portafogli specifici |
| Regole di spesa adattive avanzate | Perlopiù sperimentale | Progetti di ricerca e implementazioni pilota |
| Recupero tramite contatti fidati | Parzialmente disponibile | Alcuni portafogli specifici |
Il quadro che emerge da questa tabella è coerente con lo sviluppo tipico di uno standard tecnico complesso: le funzionalità più semplici da implementare e con un beneficio immediato più evidente per l’utente sono anche quelle adottate più rapidamente, mentre le funzionalità che richiedono un equilibrio più delicato fra sicurezza e usabilità procedono con maggiore cautela.
Perché l’adozione varia così tanto da una rete all’altra
Il funzionamento pratico di questo standard richiede un’infrastruttura di supporto specifica, inclusi soggetti che si occupano di raggruppare e trasmettere le operazioni degli utenti alla rete secondo il formato richiesto. Reti dove questa infrastruttura si è sviluppata prima offrono oggi un’esperienza più matura e affidabile di reti dove il supporto è ancora agli inizi.
Questa disparità significa che la stessa funzionalità, per esempio il pagamento delle commissioni da parte di terzi, può risultare pienamente affidabile su una rete e ancora sperimentale su un’altra, un dettaglio che chi sviluppa applicazioni deve considerare attentamente prima di promettere agli utenti finali funzionalità che dipendono da un’infrastruttura non ancora consolidata ovunque.
Un utente che valuta un’applicazione basata su questi meccanismi dovrebbe verificare su quale rete opera effettivamente, prima di dare per scontato che tutte le funzionalità descritte in questo testo siano ugualmente mature ovunque. La stessa applicazione, distribuita su più reti diverse, può offrire un’esperienza sensibilmente differente a seconda della maturità dell’infrastruttura di supporto disponibile su ciascuna di esse in un dato momento.
Chi sviluppa applicazioni professionali in questo ambito tende quindi a comunicare con chiarezza su quali reti una determinata funzionalità è pienamente supportata, evitando di presentare come uniformemente disponibile qualcosa che nella pratica varia sensibilmente da un contesto all’altro, una prassi di trasparenza che aiuta gli utenti a formarsi aspettative corrette prima di affidare fondi rilevanti a un nuovo strumento.
Che cosa significa per chi usa un dispositivo di firma hardware
Chi custodisce le proprie chiavi su un dispositivo di firma dedicato, invece che su un’applicazione da telefono, può chiedersi se questi progressi lo riguardino o restino confinati a un mondo di applicazioni puramente software. La risposta dipende da come il dispositivo si integra con un account programmabile: in alcune configurazioni, il dispositivo hardware resta responsabile della sola firma finale, mentre la logica di regole di spesa e di recupero risiede nel contratto dell’account, mantenendo così il vantaggio di sicurezza del dispositivo dedicato insieme alla flessibilità offerta dallo standard.
Questa combinazione non è ancora universalmente disponibile su tutti i modelli di dispositivo in commercio, e chi valuta l’acquisto di un nuovo dispositivo dovrebbe verificare esplicitamente se il produttore dichiara compatibilità con gli account programmabili, un criterio che si aggiunge a quelli già discussi a proposito di come scegliere un dispositivo di firma hardware in base a criteri tecnici verificabili piuttosto che alla sola reputazione del marchio.
Nel tempo, è ragionevole aspettarsi che questa integrazione diventi più comune, dato che i due approcci risolvono problemi complementari piuttosto che concorrenti: il dispositivo hardware protegge il momento della firma da un dispositivo compromesso, mentre l’account programmabile protegge da errori operativi e permette una gestione più flessibile del rischio complessivo dell’account.
Domande frequenti
ERC-4337 richiede una modifica al protocollo di base della rete?
No, è progettato per funzionare come livello aggiuntivo sopra l’infrastruttura esistente, senza richiedere modifiche al protocollo di consenso di base della rete, il che ha permesso un’adozione più rapida rispetto a proposte che avrebbero richiesto un cambiamento più profondo.
Un account che usa questo standard è più sicuro di uno tradizionale?
Dipende dalle regole configurate. Un account programmabile può essere sia più sicuro, grazie a limiti di spesa e recupero distribuito, sia più complesso da verificare, perché la sua sicurezza dipende dalla correttezza del codice che ne definisce le regole, non solo dalla protezione di una singola chiave.
Posso convertire un account tradizionale esistente in uno programmabile?
In alcuni casi sì, attraverso procedure specifiche offerte da determinati portafogli, ma il processo e le implicazioni tecniche variano a seconda della rete e dello strumento utilizzato, ed è consigliabile informarsi sulla procedura esatta prima di procedere.
Chi paga effettivamente la commissione quando un paymaster la copre per me?
Il paymaster stesso, secondo un modello economico definito dall’applicazione che lo gestisce, che può recuperare il costo in altri modi, per esempio tramite una commissione sul servizio offerto o come strategia di acquisizione di nuovi utenti.
Le regole di spesa programmabili funzionano offline?
No, la verifica delle regole richiede l’interazione con l’infrastruttura di rete al momento dell’esecuzione della transazione, quindi non sono applicabili a operazioni pensate per funzionare completamente senza connessione, un limite da tenere presente per chi progetta procedure di firma isolate dalla rete.
ERC-4337 non è una promessa unica da valutare come vera o falsa nel suo insieme: è un insieme di funzionalità distinte, alcune già solide nell’uso quotidiano, altre ancora in fase di maturazione, ed è quella distinzione, più che l’entusiasmo generico attorno allo standard, a determinare che cosa un utente può davvero aspettarsi oggi dal proprio portafoglio.
