Nonce durevoli: firma con due dispositivi su Solana

SSP è un wallet 2 di 2. Ogni transazione richiede due firme: una dalla Wallet, l'estensione del browser sul tuo computer, e una da SSP Key sul tuo telefono. È in questo che sta tutto il senso del design — un ladro che ruba un dispositivo non può comunque muovere i tuoi fondi. Ma ciò introduce un problema molto umano. Il computer costruisce e firma una transazione in una frazione di secondo. Il telefono potrebbe cofirmare solo due o tre minuti dopo, perché una persona deve prendere il telefono, guardare la richiesta e toccare approva.

Su Solana, questo intervallo è un problema. Questo articolo spiega perché, e come SSP lo risolve senza conservare nulla di fragile.

Il blockhash che scade

Ogni normale transazione di Solana porta con sé un dato chiamato blockhash recente. È l'impronta di un blocco recente della catena, e svolge due compiti insieme. Dimostra che la transazione è stata creata di recente e impedisce che la stessa transazione firmata venga riprodotta per sempre.

Il trucco sta nella parola recente. Un blockhash è valido solo per circa 150 blocchi. Su Solana i blocchi arrivano in fretta, quindi 150 blocchi sono appena circa 60-90 secondi. Trascorsa quella finestra, la rete rifiuta la transazione di netto — non perché ci sia qualcosa di sbagliato nelle firme, ma perché il blockhash è scaduto.

Ora metti il flusso di firma di SSP contro quell'orologio. La Wallet costruisce la transazione, fissa un blockhash fresco e firma. Poi l'utente viene notificato sul telefono. Se risponde entro 90 secondi, bene. Se è in riunione, il telefono è in un'altra stanza, oppure vuole semplicemente leggere la transazione con calma, il blockhash muore in silenzio. La firma della Wallet è ancora crittograficamente valida, ma la transazione a cui era allegata ora non vale nulla. Tutto va ricostruito e rifirmato da zero.

Per un wallet a singolo firmatario che firma e trasmette in un solo respiro, la finestra di 90 secondi è generosa. Per un wallet 2 di 2 in cui un essere umano sta tra le due firme, è una corsa che l'utente continua a perdere.

Cos'è un nonce durevole

Solana ha una risposta integrata a questo, ed è precedente a SSP: il nonce durevole. L'idea è sostituire il blockhash che scade con un valore che non scade.

Un nonce durevole vive in un proprio piccolo account sulla catena — un account di nonce. Questo account appartiene al sistema, contiene solo 80 byte di dati, e uno di quei dati è il valore del nonce stesso: un sostituto a lunga durata per un blockhash. Una transazione può essere costruita per usare il valore dell'account di nonce al posto di un blockhash recente. Poiché quel valore non invecchia, la transazione resta valida per tutto il tempo necessario — minuti, ore, giorni.

Nulla è gratis, però, e un nonce ha bisogno di una protezione contro il replay. Quella protezione è una regola: ogni transazione che usa un nonce durevole deve portare un'istruzione specifica, nonceAdvance, come sua prima istruzione. Quando la transazione finalmente atterra, nonceAdvance consuma il valore di nonce corrente e ruota l'account a uno nuovo. Il nonce è monouso. La transazione che hai firmato lunedì può aspettare fino a mercoledì, ma una volta eseguita, proprio quel nonce non potrà mai più autorizzare un'altra transazione. Se vuoi leggere la descrizione del meccanismo fatta da Solana stessa, la documentazione sui nonce di transazione durevoli è la fonte primaria.

Così un nonce durevole compra tempo senza comprare un rischio di replay. È esattamente la proprietà di cui ha bisogno un wallet a due dispositivi.

La svolta di SSP: un account di nonce che non devi mai conservare

Un account di nonce durevole è pur sempre un account, e su Solana ogni account ha un indirizzo. L'approccio ingenuo è creare un account di nonce a un indirizzo casuale e poi ricordare con cura quell'indirizzo per sempre — scriverlo nella memoria locale del wallet, farne un backup, sperare che sopravviva a un ripristino del dispositivo. È un'altra cosa fragile da perdere.

SSP si rifiuta di conservarlo. Invece, il programma multisig di SSP per Solana include un'istruzione chiamata provision_nonce, e crea l'account di nonce a un indirizzo derivato. L'indirizzo proviene da una ricetta deterministica: viene calcolato dall'account multisig stesso, dall'etichetta di testo fissa "nonce" e dal programma di sistema di Solana. Lo stesso multisig in ingresso, lo stesso indirizzo di nonce in uscita — ogni volta.

Questo conta per via di ciò che il resto di questa serie ha già stabilito. Il multisig di SSP per Solana deriva l'indirizzo del multisig dall'insieme dei membri, e deriva l'indirizzo del caveau dal multisig. (Se queste derivazioni ti sono nuove, l'articolo multisig auto-inizializzante di Solana le percorre.) L'account di nonce ora si unisce alla stessa famiglia: anche esso è una pura derivazione. Qualsiasi dispositivo SSP — il tuo computer, il tuo telefono, un wallet appena reinstallato — può ricalcolare l'indirizzo dell'account di nonce da zero. Non c'è alcun indirizzo segreto da perdere, perché non c'è alcun indirizzo conservato.

Dal design seguono alcune note pratiche. provision_nonce è senza permesso (permissionless): chiunque può pagare il piccolo affitto (circa 0,00144 SOL) per far esistere l'account di nonce, e chi paga ne diventa l'autorità iniziale — in pratica il paymaster del relay di SSP. Quell'autorità può essere riassegnata in seguito senza che l'indirizzo dell'account cambi mai, così l'indirizzo che derivi oggi resta corretto anche se la chiave operativa dietro di esso ruota. La posizione dell'account di nonce è ancorata al tuo multisig, non a chi lo ha finanziato.

Il flusso di firma sereno

Metti insieme i pezzi e la corsa scompare. La Wallet costruisce una transazione che usa l'account di nonce derivato invece di un blockhash recente, colloca nonceAdvance come prima istruzione e firma. Una notifica push parte verso il telefono. L'utente approva quando è pronto — nessun orologio corre contro di lui. SSP Key aggiunge la seconda firma, e la transazione completamente firmata viene trasmessa. Poiché è stata costruita su un nonce durevole, è ancora valida, e nonceAdvance ruota il nonce in modo che la transazione non possa essere riprodotta.

C'è un altro vincolo che vale la pena nominare. Solana limita una singola transazione a 1232 byte. Una transazione multisig deve far stare la lista dei membri e le istruzioni di spesa dentro quel limite, ed è per questo che SSP usa il formato compatto di transazione versionata di Solana e passa i dati nel modo più stretto possibile. Il nonce durevole non cambia il budget di dimensione; cambia solo il budget di tempo.

Derivare tutto, conservare nulla

È questo il filo che attraversa l'intera serie Multisig su Solana, alla maniera SSP. L'indirizzo del multisig, il caveau che custodisce i tuoi fondi e ora l'account di nonce che dà a due dispositivi il tempo di mettersi d'accordo — nessuno di essi è un valore che SSP deve salvare e proteggere. Ciascuno viene ricalcolato su richiesta da input che il wallet già conosce. C'è meno da salvare, meno che possa trapelare e meno che possa andare storto in un ripristino del dispositivo. I design di multisig che si appoggiano a questa idea, come l'approccio del multisig a singolo firmatario di SSP, tendono a essere quelli con il minor numero di parti mobili che si possono rompere.

Una nota finale nello stesso spirito di onestà del resto della serie: il programma multisig di SSP per Solana è attualmente distribuito solo su devnet, ed è in attesa di un audit di sicurezza esterno prima di qualunque rilascio su mainnet. Il design descritto qui — incluso provision_nonce e il suo account di nonce derivato — è reale e leggibile nel programma open source, ma non è ancora infrastruttura di produzione. Se il modello a due dispositivi di SSP stesso ti è nuovo, l'articolo introduttivo cos'è il multisig 2 di 2 è il posto da cui partire.

Il nonce durevole è un piccolo e vecchio pezzo dell'idraulica di Solana. Il contributo di SSP è rendere il suo indirizzo un'altra cosa che non devi mai ricordare.