Dentro l'architettura di astrazione dei conti di SSP

SSP è un wallet auto-custodiale costruito attorno a un multisig 2-di-2. Una chiave risiede nell'estensione per browser SSP Wallet, la seconda nell'app mobile SSP Key, e nessuna transazione viene regolata se entrambi i dispositivi non la approvano. Sulle catene EVM, SSP mantiene questa garanzia con l'account abstraction di ERC-4337: il wallet è uno smart account la cui logica di validazione accetta un'unica firma Schnorr aggregata costruita a partire dalle due chiavi. Questo articolo percorre quell'architettura da un capo all'altro: ogni componente, il flusso di firma esatto e la proprietà di sicurezza che produce.

Se l'account abstraction è nuova per te, parti da L'astrazione dei conti dai primi principi e dalla spiegazione mirata di ERC-4337. Qui diamo per scontato che tu sappia per sommi capi cosa siano uno smart account e una UserOperation, e ci concentriamo su come SSP li collega tra loro.

I pezzi su cui SSP fa affidamento

Prima di tracciare il flusso, è utile dare un nome ai componenti e a ciò che ciascuno fa:

• Lo smart account. Sulle catene EVM il tuo wallet SSP non è una EOA controllata da una sola chiave. È uno smart account ERC-4337: un contratto che custodisce i tuoi fondi e contiene la propria logica di validazione. Quella logica è il cuore del progetto: accetta una transazione solo quando la firma fornita corrisponde alla chiave aggregata attesa del wallet.
• I due dispositivi. La chiave 1 risiede nell'estensione per browser SSP Wallet. La chiave 2 risiede nell'app mobile SSP Key. Ogni dispositivo custodisce una quota e produce una firma parziale. Nessuna quota può autorizzare alcunché da sola.
• La UserOperation. Invece di una transazione normale, l'estensione esprime la tua intenzione come una UserOperation: un oggetto strutturato che descrive cosa l'account deve fare e la firma che lo autorizza.
• Il bundler. Un bundler preleva la UserOperation dal mempool dedicato, la impacchetta in una vera transazione on-chain e paga il gas dello strato base per inviarla.
• L'EntryPoint. Un unico contratto EntryPoint sottoposto ad audit è l'ingresso on-chain di ogni operazione ERC-4337. Chiama il tuo smart account per eseguire la logica di validazione di quell'account e poi innesca l'esecuzione se la validazione passa.

Un paymaster può, facoltativamente, coprire il gas di una UserOperation; è un tema a sé, trattato in Sponsorizzazione del gas e paymaster spiegati.

Il flusso di firma esatto

Ecco cosa accade, passo dopo passo, quando invii una transazione da SSP su una catena EVM:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Letto in prosa:

1. Avvii una transazione nell'estensione per browser SSP Wallet, che custodisce la chiave 1.
2. L'estensione costruisce una UserOperation ERC-4337 che descrive l'azione.
3. La chiave 1 produce una firma Schnorr parziale su quell'operazione.
4. La richiesta viene inviata all'app mobile SSP Key (chiave 2) per l'approvazione.
5. La chiave 2 produce la propria firma parziale.
6. Le due parziali vengono aggregate, in stile MuSig2 su secp256k1, in un'unica firma Schnorr.
7. La UserOperation, che ora porta quell'unica firma aggregata, è pronta per l'invio.
8. Va a un bundler, che la impacchetta in una transazione e paga il gas.
9. Il bundler la invia al contratto EntryPoint, che invoca lo smart account di SSP. L'account valida l'unica firma aggregata rispetto alla chiave aggregata attesa del wallet e, se valida, esegue la chiamata.

Entrambi i dispositivi sono necessari per arrivare al passo 6, ed è questo che lo rende un vero 2-di-2. Togli una qualsiasi delle parziali e l'aggregazione non potrà produrre una firma che il contratto accetti.

Perché la catena vede una sola firma

Il dettaglio che rende elegante il progetto di SSP è l'aggregazione al passo 6. L'estensione e il telefono non allegano ciascuno una firma separata all'operazione. Le loro due firme Schnorr parziali si combinano — in stile MuSig2, sulla stessa curva secp256k1 che Ethereum già usa — in un'unica firma Schnorr. Lo smart account verifica quell'unica firma rispetto a un'unica chiave aggregata attesa.

Questo ha due conseguenze su cui vale la pena soffermarsi:

• L'impronta on-chain resta piccola. La UserOperation porta una firma, non due. Non c'è un elenco di firmatari da memorizzare o scorrere, né un ciclo di verifica per ciascun firmatario. Il contratto svolge la stessa quantità di lavoro di validazione che svolgerebbe per un singolo firmatario.
• La catena non può capire che è multisig. Ciò che arriva all'EntryPoint sembra un'ordinaria operazione firmata. L'imposizione del 2-di-2 sta nel modo in cui la firma è stata prodotta — attraverso due dispositivi — e non in qualche struttura multiparte visibile sulla catena. Per un osservatore esterno il wallet si comporta come qualsiasi altro smart account.

Questa è la differenza tra l'approccio di SSP e un multisig ingenuo che pubblica N firme separate e ne verifica ciascuna. La meccanica del fare multisig in questo modo su EVM è approfondita in Il multisig EVM alla maniera dell'astrazione dei conti.

Cosa protegge davvero ciascun dispositivo

Vale la pena essere precisi sulla proprietà di sicurezza, perché è l'intero scopo dell'architettura.

• Nessuna chiave da sola può muovere fondi. La chiave 1 nell'estensione può costruire una UserOperation e firmare la propria metà, ma una mezza firma si aggrega in qualcosa che il contratto non accetterà. La chiave 2 sul telefono può approvare e firmare la propria metà, ma non può originare né completare un trasferimento da sola.
• Compromettere un dispositivo non basta. Un aggressore che controlla del tutto la tua estensione per browser non può comunque spendere, perché senza il telefono non può produrre la firma parziale della chiave 2. Vale anche il contrario. Il modello di minaccia a cui una EOA a chiave singola non sopravvive — una chiave trapelata, perdita totale — qui non si applica.
• L'approvazione è esplicita e su un secondo schermo. Poiché il passo 4 invia la richiesta all'app SSP Key, vedi e approvi l'operazione su un dispositivo fisicamente separato prima che possa essere aggregata e inviata.

È la stessa proprietà 2-di-2 descritta in Cos'è il multisig 2-di-2?, realizzata sulle catene EVM tramite l'astrazione dei conti anziché un opcode multisig nativo.

I vantaggi, riassunti

Tirando le fila, l'architettura offre agli utenti di SSP una combinazione specifica difficile da ottenere altrimenti:

• Sicurezza multisig su ogni catena EVM supportata. Lo stesso progetto 2-di-2 gira su Ethereum, Polygon, Base, BNB Smart Chain e Avalanche, perché ERC-4337 è uno standard a livello di contratto e non una funzionalità specifica di una catena.
• Una piccola impronta on-chain. Un'unica firma aggregata significa che lo smart account valida come un singolo firmatario, mantenendo snella la verifica.
• UX simile a quella di un singolo firmatario. Dal tuo lato è come approvare una transazione su due dispositivi, non come assemblare un comitato. Non ci sono indirizzi di co-firmatari da gestire né un contratto multisig separato da configurare per ogni trasferimento.
• Nessuna modifica al protocollo richiesta. Poiché tutto poggia su ERC-4337, SSP ottiene tutto questo senza attendere che l'astrazione dei conti a livello dello strato base venga rilasciata.

Una nota sull'audit

Un'architettura di sicurezza è affidabile quanto la sua revisione. Gli smart contracts di SSP sono stati sottoposti ad audit da Halborn nel 2025. Un audit esterno non rende infallibile alcun sistema, ma è un segnale di fiducia significativo per la logica del contratto che impone la regola 2-di-2 descritta sopra.

Dove andare adesso

Questo articolo ha tracciato l'astrazione dei conti di SSP da un capo all'altro. Per approfondire lo standard e i concetti circostanti:

• L'astrazione dei conti dai primi principi — perché le EOA sono limitanti e cosa significa astrazione dei conti.
• Cos'è l'astrazione dei conti (ERC-4337)? — lo standard preso isolatamente, inclusi i ruoli della UserOperation, del bundler e dell'EntryPoint.
• Sponsorizzazione del gas e paymaster spiegati — come un paymaster può coprire il gas di una UserOperation.
• Il multisig EVM alla maniera dell'astrazione dei conti — la meccanica del multisig su EVM più in dettaglio.

Per la specifica formale, vedi EIP-4337; per lo sforzo più ampio, la roadmap dell'astrazione dei conti di Ethereum segue dove si sta dirigendo. La conclusione: SSP trasforma la promessa astratta di un account programmabile in un concreto wallet 2-di-2, dove due dispositivi producono una firma e la catena vede semplicemente un'operazione valida.