L'account abstraction oltre Ethereum
L'account abstraction viene spesso presentata come una storia di Ethereum — un modo per trasformare un wallet a chiave singola in uno smart account programmabile tramite ERC-4337. Ma l'idea non si ferma a Ethereum L1. Si propaga lungo due strade molto diverse: verso l'esterno, attraverso le catene EVM che condividono il modello di esecuzione di Ethereum, e in modo nativo, dentro catene progettate fin dal primo giorno con l'account abstraction integrata nel protocollo. Questo articolo traccia la mappa di quel panorama più ampio, spiega in cosa l'account abstraction nativa differisce dallo standard ERC-4337 sovrapposto a Ethereum, e presta particolare attenzione a un confine: dove finisce l'ecosistema generale e dove inizia ciò che SSP supporta davvero.
Questo è l'ultimo articolo della nostra serie sull'account abstraction. Se i concetti di base sono nuovi per te, parti da L'account abstraction dai primi principi, poi confronta i due modelli di account in EOA contro smart account: le differenze che contano. Qui diamo per scontato che tu sappia all'incirca cos'è uno smart account e allarghiamo lo sguardo al resto del mondo cripto.
Lo stesso standard, ovunque giri l'EVM
Il primo modo in cui l'account abstraction si diffonde è il più semplice: viaggia insieme all'EVM. ERC-4337 non è una modifica del protocollo base. È uno standard a livello di contratto costruito su un contratto EntryPoint, oggetti UserOperation, bundler e paymaster opzionali — nulla di tutto ciò richiede modifiche al consenso. Questa scelta progettuale ha una conseguenza potente. Qualsiasi catena che esegua la Ethereum Virtual Machine può ospitare lo stesso EntryPoint, la stessa infrastruttura di bundler e gli stessi contratti di smart account.
È proprio per questo che i principali L2 e sidechain EVM supportano ERC-4337 nello stesso modo di Ethereum:
- Polygon esegue l'EVM, quindi lo stesso contratto di smart account e lo stesso
EntryPointvengono distribuiti senza modifiche. - Base è un L2 EVM dove l'account abstraction ERC-4337 funziona come su L1.
- BNB Smart Chain è compatibile con l'EVM e ospita lo stesso standard.
- Avalanche C-Chain esegue l'EVM e supporta la stessa account abstraction a livello di contratto.
Poiché lo standard è portabile, la logica di smart account di un wallet scritta per Ethereum si trasferisce a queste catene praticamente invariata. È esattamente questa portabilità che consente a SSP di far girare il proprio design su ogni catena EVM che supporta — lo stesso contratto 2-di-2 si comporta in modo identico, che sia distribuito su Ethereum, Polygon, Base, BNB Smart Chain o Avalanche. Per la vista pratica, catena per catena, dell'uso di SSP su queste reti, vedi Usare SSP su Polygon, Base e altre catene EVM.
Account abstraction nativa: quando è il protocollo, non uno strato
Il secondo modo in cui l'account abstraction si diffonde è radicalmente diverso. Alcune catene non hanno aspettato uno standard opzionale — hanno integrato l'account abstraction direttamente nel protocollo, così che non esiste alcuna distinzione tra «EOA e smart account». Ogni account è uno smart account per impostazione predefinita.
Starknet: ogni account è un contratto
Starknet ha l'account abstraction fin dal primo giorno. Su Starknet non esistono account a proprietà esterna nel senso di Ethereum; ogni account è un account di contratto, scritto nel linguaggio Cairo. Poiché il comportamento dell'account è definito da codice di contratto a livello di protocollo, gli schemi di firma, le regole di validazione, il multisig e la logica delle commissioni sono proprietà dell'account stesso e non funzionalità aggiunte in un secondo momento.
Il contrasto con Ethereum è istruttivo. Su Ethereum, l'account predefinito è una EOA con un'unica verifica ECDSA cablata, ed ERC-4337 esiste per sovrapporre account programmabili al di sopra senza un hard fork. Su Starknet non c'è nulla da sovrapporre — l'account programmabile è la base. Non c'è uno standard EntryPoint separato da adottare, perché l'account abstraction non è opzionale. La documentazione di Starknet su docs.starknet.io descrive in dettaglio questo modello di account.
zkSync Era: AA nativa con paymaster integrati
zkSync Era adotta un approccio nativo del protocollo simile. L'account abstraction fa parte del protocollo anziché essere un'aggiunta, e il sistema include il supporto integrato per i paymaster a livello di protocollo. Su Ethereum, un paymaster è un contratto definito dallo standard ERC-4337 e instradato attraverso l'EntryPoint; su zkSync Era, la funzionalità di paymaster è una caratteristica di prima classe della catena stessa, quindi sponsorizzare le commissioni o pagare il gas in un altro token fa parte di come la rete è progettata per funzionare. La documentazione di zkSync copre la sua account abstraction nativa e il suo modello di paymaster.
AA nativa contro ERC-4337: la differenza essenziale
Vale la pena enunciare chiaramente la distinzione, perché è il cuore concettuale di questo articolo:
- ERC-4337 è uno standard opzionale sovrapposto a un protocollo invariato. Il livello base di Ethereum comprende ancora nativamente soltanto le EOA e la loro unica firma ECDSA. Gli smart account esistono perché gli sviluppatori si sono accordati su un insieme comune di componenti on-chain e off-chain — l'
EntryPoint, il mempool alternativo, i bundler — che simulano l'account abstraction a livello di protocollo senza un cambio di consenso. È geniale proprio perché non ha richiesto alcun hard fork, ed è portabile su ogni catena EVM per la stessa ragione. - L'account abstraction nativa è integrata nel protocollo. Su Starknet e zkSync Era, la catena stessa tratta ogni account come programmabile. Non c'è opzione, nessuno standard separato da adottare, né distinzione tra un account «normale» e uno intelligente — lo smart account è l'account.
Entrambe offrono all'utente finale gli stessi vantaggi: più firmatari, validazione personalizzata, logica di recupero e gas flessibile. Arrivano semplicemente da direzioni opposte — una come uno strato accuratamente progettato, l'altra come una decisione fondante del protocollo. Se vuoi la specifica formale dell'approccio a strati, EIP-4337 è il riferimento canonico.
Dove si colloca SSP — e dove no
Questo è il confine su cui essere precisi. SSP è un wallet auto-custodiale costruito attorno a un multisig 2-di-2: una chiave nell'estensione del browser SSP Wallet, la seconda nell'app mobile SSP Key, senza che alcun dispositivo possa muovere fondi da solo. Sulle catene EVM, SSP lo implementa come uno smart account ERC-4337 la cui logica di validazione verifica un'unica firma Schnorr aggregata costruita a partire da entrambe le chiavi. Gli smart contracts di SSP sono stati sottoposti ad audit da Halborn nel 2025.
Poiché ERC-4337 è portabile su tutto l'EVM, l'approccio di SSP si trasferisce alle catene EVM che supporta: Ethereum, Polygon, Base, BNB Smart Chain e Avalanche C-Chain. Lo stesso contratto di smart account 2-di-2 gira su tutte.
Starknet e zkSync Era compaiono in questo articolo come parte dell'ecosistema più ampio — esempi di catene in cui l'account abstraction è nativa del protocollo. Non fanno parte dell'insieme di catene supportate da SSP. SSP porta l'account abstraction ERC-4337 sulle catene EVM elencate sopra; non gira su Starknet, zkSync Era o altre catene non-EVM. Quando leggi dell'AA nativa altrove nel mondo cripto, trattala come contesto su quanto si sia diffuso il modello di smart account, non come un'affermazione su dove opera SSP.
Perché questo conta
Facendo un passo indietro, lo schema è chiaro: l'esperienza dello smart account sta diventando lo standard in gran parte del mondo cripto, non una funzionalità di nicchia per utenti esperti.
- Sull'EVM, ERC-4337 porta account programmabili a Ethereum e a ogni catena compatibile senza un hard fork, ed è ciò che permette a un wallet come SSP di offrire su Polygon, Base, BNB Smart Chain e Avalanche la stessa sicurezza 2-di-2 che offre su Ethereum.
- Sulle catene con astrazione nativa, la domanda «è una EOA o uno smart account?» semplicemente non si pone, perché esiste un solo tipo di account ed è programmabile.
Per un utente in auto-custodia, la conclusione è che il rigido modello a chiave singola non è più l'unica opzione e, sempre di più, non è quella predefinita. Che l'account abstraction arrivi come standard a strati o come funzionalità nativa del protocollo, la destinazione è la stessa: account che puoi programmare, con regole di sicurezza — come il multisig a due dispositivi di SSP — che una singola chiave privata non potrebbe mai imporre da sola. Per rivedere come questo modello si confronta con l'account Ethereum originale, vedi EOA contro smart account: le differenze che contano, e per lo standard preso isolatamente, Cos'è l'account abstraction (ERC-4337)?.
