
L'astrazione degli account a partire dai primi principi
Se hai mai usato un wallet auto-custodiale su Ethereum, hai usato un account di proprietà esterna — una EOA — che tu lo sapessi o no. Il discorso sull'astrazione degli account inizia dal capire cos'è una EOA, perché il suo design vincola tutto ciò che puoi fare on-chain e come l'astrazione degli account di ERC-4337 aggiri questi vincoli senza toccare il protocollo di base. Questo articolo è il punto di ingresso di una serie che ti porta dai vincoli originari fino a come SSP usa l'astrazione degli account per far funzionare il suo multisig 2-su-2 sulle catene EVM.
Questo è il pezzo fondativo e concettuale. Per una trattazione mirata dello standard ERC-4337 in sé, leggi Cos'è l'astrazione degli account (ERC-4337)? insieme a questo; qui costruiamo l'intuizione del perché lo standard esiste.
L'account che Ethereum ti ha dato
Ethereum ha due tipi di account. Gli account di contratto sono governati dal codice. Le EOA — i comuni wallet che la maggior parte delle persone usa — sono governate da una sola chiave privata. Chi possiede quella chiave può autorizzare qualsiasi transazione dall'account, e il protocollo convalida esattamente una cosa: che la transazione porti una firma ECDSA valida sulla curva secp256k1, prodotta dalla chiave che controlla l'indirizzo.
Quell'unica regola è elegante ed è anche l'origine di ogni vincolo discusso più avanti. La validità di una transazione è cablata nel protocollo. Tu, proprietario dell'account, non puoi decidere cosa significhi "valida". Decide il protocollo, e sa controllare un solo schema di firma di una sola chiave.
Ciò che quel design incorpora alla radice
Quattro vincoli discendono direttamente dal modello a una chiave, una firma:
- Una sola chiave è un singolo punto di guasto. Perdi la chiave e i fondi spariscono. Falla trapelare e un aggressore ha tutto. Non c'è un secondo fattore a livello di protocollo, né un cofirmatario, né una policy che avrebbe potuto bloccare il furto.
- Nessuna logica di convalida personalizzata. Una EOA non può dire "richiedi due firme", né "consenti automaticamente questo piccolo pagamento ma richiedi un'approvazione extra oltre una soglia", né "lascia che questa chiave spenda solo nei giorni feriali". L'account non ha logica. Ha un controllo della firma.
- Il mittente deve detenere ETH per il gas. Ogni transazione di una EOA paga il proprio gas in ETH. Un nuovo utente che detiene solo un token ERC-20 ma niente ETH non può muovere quel token, perché non può pagare la commissione. Chi paga la commissione e chi invia la transazione sono costretti a essere lo stesso account.
- La UX della seed phrase è spietata. Poiché la chiave è l'account, l'iscrizione significa annotare una seed phrase e proteggerla per sempre. Non esiste un percorso di recupero che non coinvolga quella frase, e un singolo errore è permanente.
Non sono bug. Sono le conseguenze del fatto che la convalida risiede nel protocollo invece che nell'account.
L'idea centrale: rendere l'account programmabile
L'astrazione degli account è l'idea di togliere quella logica di convalida dal protocollo e collocarla nell'account stesso. Invece che la rete codifichi rigidamente "una transazione è valida se ha una firma ECDSA corretta", uno smart account — un contratto che custodisce i tuoi fondi — decide da sé cosa conti come transazione valida.
Una volta che l'account è un contratto programmabile, i quattro vincoli si dissolvono in scelte di progettazione:
- Può richiedere due firme invece di una, che è esattamente il modo in cui il multisig diventa possibile senza supporto nativo del protocollo.
- Può implementare regole di recupero, così che una chiave persa non sia più la fine della storia.
- Può lasciare che paghi il gas qualcun altro, separando chi paga la commissione da chi invia.
- Può raggruppare diverse azioni — approvare e scambiare, per esempio — in un'unica operazione atomica.
L'account smette di essere una coppia di chiavi passiva e diventa logica programmabile che controlli tu.
Come ERC-4337 realizza questo senza un hard fork
La parte difficile è che cambiare il modo in cui Ethereum convalida le transazioni normalmente significa cambiare il protocollo di base — un aggiornamento lento, controverso e a livello dell'intera rete. ERC-4337 aggira tutto questo. Introduce l'astrazione degli account come uno strato sopra la rete esistente, senza richiedere modifiche al consenso.
Il meccanismo poggia su alcuni componenti:
- UserOperations. Invece di inviare una normale transazione, uno smart account esprime l'intento come una
UserOperation— un oggetto strutturato che descrive cosa l'account vuole fare e come va convalidato. - Una mempool alternativa. Le UserOperations vivono nella loro mempool, separata dalle transazioni ordinarie.
- Bundlers. Un bundler raccoglie UserOperations da quella mempool, le impacchetta insieme e le sottopone alla catena come una transazione vera e propria, pagando il gas dello strato base.
- Il contratto EntryPoint. Un unico contratto
EntryPointsottoposto ad audit è il collo di bottiglia on-chain. Chiama ciascuno smart account per eseguire la logica di convalida propria di quell'account, poi esegue l'operazione se la convalida passa. - Paymasters. Un contratto
paymasteropzionale può accettare di coprire il gas di una UserOperation, ed è ciò che rende possibili i flussi senza gas e di pagamento in token.
Messo insieme, questo consente a qualsiasi contratto di agire come un account pienamente programmabile, convalidato dalle proprie regole, mentre il protocollo Ethereum sottostante rimane esattamente com'era. Lo standard è specificato in EIP-4337, e la stessa roadmap sull'astrazione degli account di Ethereum traccia dove sta andando lo sforzo più ampio.
Perché questo conta per gli utenti dell'auto-custodia
Per chi custodisce le proprie chiavi, l'astrazione degli account non è un dettaglio astratto di protocollo: cambia ciò che un wallet può fare in sicurezza:
- Multisig senza supporto nativo. Uno smart account può esigere più di una firma, così un wallet può richiedere che due dispositivi indipendenti approvino ogni trasferimento. È il mattone su cui SSP fa affidamento, spiegato più in dettaglio in Il multisig EVM all'insegna dell'astrazione degli account.
- Opzioni di recupero. La convalida programmabile apre la porta a flussi di recupero che non collassano in un'unica fragile seed phrase.
- Sponsorizzazione del gas. I paymasters significano che la commissione può essere disaccoppiata dal mittente, smussando il peggior attrito d'iscrizione.
- Raggruppamento. Più passaggi possono essere regolati come un'unica operazione, riducendo sia i clic sia il rischio di fallire a metà strada.
La differenza pratica tra una EOA a chiave singola e uno smart account programmabile è abbastanza grande da meritare una trattazione a sé — vedi EOA contro smart account: le differenze che contano.
Dove si colloca SSP
SSP è un wallet auto-custodiale costruito attorno al multisig 2-su-2. Una chiave vive nell'estensione del browser SSP Wallet; la seconda vive nell'app mobile SSP Key. Ogni transazione viene costruita nell'estensione e cofirmata sul telefono, così nessun dispositivo da solo può muovere fondi.
Sulle catene EVM, SSP realizza quel 2-su-2 usando ERC-4337. Il wallet è uno smart account ERC-4337 la cui logica di convalida richiede entrambe le chiavi, e le due firme parziali si combinano — alla maniera di MuSig2 su secp256k1 — in un'unica firma aggregata di Schnorr che il contratto verifica on-chain. Gli smart contracts di SSP sono stati sottoposti ad audit da Halborn nel 2025. Il design completo è oggetto di L'architettura di astrazione degli account di SSP.
In altre parole, la capacità astratta descritta sopra — un account che impone la propria regola di firma multipla — è esattamente ciò che SSP trasforma in un wallet funzionante su Ethereum, Polygon, Base e le altre catene EVM supportate.
Il resto di questa serie
Questo pezzo ha impostato il problema e l'idea centrale. La serie costruisce da qui:
- L'astrazione degli account a partire dai primi principi — questo articolo: perché le EOA sono limitanti e cosa significa l'astrazione degli account.
- EOA contro smart account: le differenze che contano — un confronto diretto dei due modelli di account.
- L'architettura di astrazione degli account di SSP — come SSP cabla ERC-4337 in un wallet 2-su-2.
- Sponsorizzazione del gas e paymasters spiegati — come i paymasters disaccoppiano chi paga da chi invia.
- L'astrazione degli account su catene non-Ethereum — come la stessa idea viaggia oltre Ethereum.
Inizia con la spiegazione di ERC-4337 se vuoi lo standard in isolamento, poi torna qui per il quadro più ampio. Da lì, l'account smette di essere un vincolo e comincia a essere qualcosa attorno a cui puoi programmare.


