Solana in SSP

·7 min di lettura·Di SSP Editorial Team
Copertina SSP Academy: Solana in SSP

Solana in SSP

Solana è veloce, economica e sempre più il luogo in cui le stablecoin si muovono davvero. È anche la catena su cui il multisig in autocustodia è storicamente stato più difficile da realizzare bene — non perché la crittografia sia complicata, ma perché il modello a conti di Solana rende «un indirizzo controllato da più parti» un oggetto molto più strano di quanto non sia su Bitcoin.

SSP custodisce SOL e token SPL nello stesso multisig 2 su 2 che già usi per Bitcoin ed Ethereum: una chiave nell'estensione del browser, una chiave sul telefono, entrambe necessarie per ogni transazione. Questo articolo spiega che cosa significhi su Solana nello specifico: come viene derivato l'indirizzo, chi paga le commissioni, che cosa verificano i tuoi dispositivi e quali parti differiscono davvero dalle catene che già conosci.

La schermata della catena Solana in SSP Wallet, in modalità scura

Che cos'è Solana visto dall'autocustodia

Solana è un'unica macchina a stati globale che elabora le transazioni in parallelo anziché una alla volta. Per chi detiene le proprie chiavi contano tre proprietà più del titolo sul throughput.

Primo, tutto è un conto. Il tuo saldo, il mint di un token, il codice di un programma e i dati che il programma memorizza vivono tutti in conti dotati di indirizzo e proprietario. Secondo, i conti costano un affitto: per esistere on-chain un conto deve mantenere un saldo minimo in SOL proporzionale alla sua dimensione. Quel deposito è rimborsabile alla chiusura del conto, ma è denaro vero che deve arrivare da qualche parte. Terzo, le transazioni scadono in fretta: una normale transazione Solana fa riferimento a un blockhash recente e diventa non valida dopo circa un minuto.

Ciascuno di questi punti ha una conseguenza diretta sulla firma con due dispositivi, e ciascuno viene affrontato esplicitamente in SSP invece che nascosto. La documentazione ufficiale di Solana è la fonte primaria sul modello dei conti e dell'affitto, se vuoi la versione grezza.

Un indirizzo senza creatore

Nella maggior parte dei progetti di multisig su Solana il portafoglio va creato. Qualcuno invia una transazione che lo istituisce, e l'indirizzo risultante dipende da input scelti durante quella transazione — di norma una chiave casuale monouso. L'effetto pratico è che l'indirizzo non esiste finché un creatore non lo fa nascere, e prima di allora non può ricevere fondi.

Il programma on-chain di SSP funziona diversamente. L'indirizzo del tuo vault è un'impronta dell'insieme ordinato dei membri più la soglia di approvazione, e nient'altro. Chiunque conosca i membri e la soglia può calcolare l'indirizzo offline, prima che qualsiasi cosa tocchi la catena. La registrazione è senza permessi: il programma verifica soltanto che i membri che presenti producano davvero l'hash dell'indirizzo dichiarato, per cui registrarsi non cambia nulla su chi può spendere.

Per questo non c'è alcun creatore di cui fidarsi, nessun registrante privilegiato e nessuna chiave di amministrazione. La spesa è governata unicamente dal controllo della soglia all'interno del programma. Se vuoi il quadro completo, perché gli indirizzi multisig di Solana sono difficili affronta il problema di fondo, il multisig Solana auto-inizializzante affronta il programma, e SSP contro Squads V4 è il confronto punto per punto.

Se è il modello 2 su 2 in sé a esserti nuovo, parti da che cos'è il multisig 2 su 2.

Perché due dispositivi avevano bisogno di un nonce durevole

Ecco il problema creato dalla scadenza. La tua estensione costruisce e firma una transazione. Il telefono deve poi approvarla. Se esci dalla stanza, pranzi e torni, il blockhash a cui la transazione faceva riferimento è morto da un pezzo e va ricostruito tutto.

SSP risolve la cosa con un conto di nonce durevole derivato dal tuo indirizzo multisig. Invece di un blockhash recente, la transazione fa riferimento a un nonce che avanza solo quando la transazione viene effettivamente confermata. La finestra di firma smette di essere un cronometro. Puoi approvare sul telefono minuti od ore dopo e la transazione resta valida — ma può comunque essere usata una sola volta, perché eseguirla fa avanzare il nonce.

Il conto di nonce viene creato al primo invio, ed è uno dei due conti il cui affitto compare nel costo di quel primo invio. Nonce durevoli e firma con due dispositivi approfondisce.

Chi paga le commissioni

Su Solana il conto che paga la commissione di una transazione è il fee payer, e deve firmare. Questo crea un fastidioso problema di avvio per un multisig appena nato: il vault ha bisogno di SOL per pagare la transazione che sposterebbe il suo SOL, e i conti che richiedono affitto non esistono ancora.

SSP usa un paymaster. Il relay di SSP gestisce un conto che firma come fee payer, anticipa la commissione di rete e ogni affitto, e viene rimborsato dal tuo vault all'interno della stessa transazione. Non c'è alcun passaggio separato, nessun credito concesso e nessun modo perché il rimborso avvenga senza le tue due firme: viaggia dentro la proposta che i tuoi dispositivi approvano.

Vale la pena interiorizzare due conseguenze:

  • Non devi prefinanziare un indirizzo con SOL per il gas. Ricevi SOL, invia SOL. È al primo invio che i conti vengono creati.
  • Il primo invio costa più di quelli successivi. Il primo invio paga l'affitto permanente del conto multisig e del conto di nonce; gli invii successivi pagano poco più della commissione di rete. Le cifre esatte sono nell'articolo di questa serie dedicato alle commissioni.

Se i paymaster come concetto non ti sono familiari, sponsorizzazione del gas e paymaster, spiegati copre lo schema generale — SSP usa già la stessa idea sulle catene EVM, come descritto in Ethereum in SSP.

Che cosa puoi detenere

Solana in SSP supporta SOL nativo e token SPL. Di serie ciò include il mint ufficiale USDC di Circle e FLUX su Solana, e SSP risolve gli altri token SPL che trova nel tuo vault.

La distinzione su cui molti inciampano: su Solana non detieni un token al tuo indirizzo principale. Ogni token vive in un proprio conto token associato, di proprietà del tuo indirizzo, uno per mint. Anche quel conto richiede un affitto, ed è il motivo per cui inviare un token SPL a qualcuno che non ha mai posseduto quel token costa un po' di più: stai pagando per far esistere il suo conto token. SSP lo crea automaticamente come parte del trasferimento anziché fallire con un errore, e l'articolo di questa serie sui conti token ne dettaglia il funzionamento.

Composizione di un invio Solana in SSP Wallet, in modalità scura

Che cosa controllano i tuoi dispositivi prima che tu firmi

Le transazioni Solana sono opache in un modo in cui quelle Bitcoin non lo sono. Ciò che una transazione fa risiede nei dati di istruzione, e un portafoglio deve decodificarli prima di poterti dire qualcosa di vero. Un portafoglio che si limita a mostrare quanto gli ha detto un server ti sta chiedendo di fidarti del server.

SSP decodifica la transazione sui tuoi dispositivi, byte per byte, usando la libreria open source @runonflux/solana-multisig. Destinatario, importo e mint del token vengono letti dai byte grezzi e confrontati con quanto viene mostrato. Se non coincidono, la firma viene bloccata del tutto: una discrepanza a quel punto indica un attacco in corso, non un difetto di visualizzazione. Nei trasferimenti SPL i decimali del token sono incorporati nell'istruzione firmata stessa, cosicché un mint che dichiari decimali diversi fa sì che il programma on-chain rifiuti la transazione.

Lo stesso principio governa il programma: le build di mainnet sono riproducibili dal sorgente pubblicato, quindi il bytecode distribuito all'indirizzo SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r può essere ricostruito e confrontato in modo indipendente. Un'affermazione sulla sicurezza vale esattamente quanto la tua possibilità di verificarla di persona.

Come iniziare

Aggiorna SSP Wallet e SSP Key all'ultima versione, poi abilita Solana dal selettore delle catene. Con la sincronizzazione in blocco della v2 puoi attivarla insieme a qualsiasi altra catena con una sola approvazione sul telefono. Se non hai ancora configurato SSP, configurare il tuo primo portafoglio SSP è il punto di partenza.

Da lì in poi Solana si comporta come ogni altra catena in SSP: rientra nel totale del tuo portafoglio, gli invii seguono lo stesso flusso comporre → rivedere → approvare con l'indirizzo del destinatario per intero sullo schermo, e ogni transazione è cofirmata da entrambi i tuoi dispositivi. L'annuncio del lancio su mainnet racconta che cosa è stato rilasciato e quando.

Condividi questo articolo

Articoli correlati