Una proposta ormai in circolazione tra i contributori di Zcash, la criptovaluta incentrata sulla privacy, rimuoverebbe il meccanismo che rende non valide le transazioni firmate in sospeso a ogni network upgrade (NU), dopo che l'ultima attivazione ha lasciato i wallet incapaci di spendere fino al rilascio di nuove versioni o firmware.

Un reclamo recente, con un esempio recente

In un post sul forum del 9 novembre, lo sviluppatore ValarDragon ha inserito la rimozione degli aggiornamenti del consensus branch ID tra i sette obiettivi di NU8, il prossimo upgrade, con l'obiettivo dichiarato di porre fine allo schema di "rompere i wallet a ogni NU".

Il reclamo ha alle spalle un esempio fresco. NU7 si è attivato la scorsa settimana al blocco 3.543.405 senza toccare il formato delle transazioni, eppure, come ha fatto notare nel medesimo thread l'utente del forum strahncryptography, ogni wallet ha comunque avuto bisogno di una nuova release o di un nuovo firmware prima di poter spendere di nuovo. Chiunque usasse un telefono air-gapped o un dispositivo non supportato è rimasto bloccato.

Per la mattina successiva, il thread aveva prodotto tre posizioni: eliminare il meccanismo, mantenerlo ma consentire agli utenti di escludersi, oppure accettare che il vero problema sia l'obsolescenza dei wallet piuttosto che la scadenza delle firme. Uno sviluppatore di vault ha poi mostrato perché la scelta non è puramente teorica.

Cosa si rompe davvero

Ogni firma Zcash si impegna su un consensus branch ID, un'etichetta per il set di regole in vigore. ZIP 200, una delle Zcash Improvement Proposals (ZIP) che specificano le regole del protocollo, l'ha introdotto affinché una transazione firmata per una catena non possa essere replicata su un fork che condivide la stessa cronologia. Quando un upgrade si attiva, l'ID cambia, e tutto ciò che è stato firmato sotto quello precedente è morto all'arrivo.

Lo ZIP di deployment di NU7 lo spiega esplicitamente per l'upgrade appena avvenuto: le transazioni di versione 5 e 6 hanno mantenuto la loro struttura, ma una transazione resta comunque non valida attraverso l'attivazione perché le sue firme vincolano il branch ID. Le transazioni salvate e firmate offline, aggiunge il documento, richiedono gli stessi controlli di attivazione di quelle in tempo reale.

Ecco perché i wallet hanno dovuto rilasciare aggiornamenti per un upgrade che non ha cambiato nulla nel modo in cui costruiscono le transazioni. Un wallet che non conosce il nuovo ID firma per una catena che non esiste più.

Il vault che non riesce a firmare in tempo

Daniel Gorgonha, che sviluppa il vault Konclave t-of-n presso Deega Labs, ha descritto più avanti nel thread il costo pratico. Konclave costruisce prima la transazione e raccoglie successivamente le firme di soglia, quindi ogni firmatario richiesto deve agire all'interno della finestra di scadenza della transazione, circa 50 minuti. Un upgrade che cade nel mezzo di quella finestra invalida tutto.

La cifra di 50 minuti proviene da ZIP 203, che ha mantenuto la scadenza predefinita a circa quella lunghezza attraverso tre modifiche del tempo di blocco. Da NU7, ciò significa 120 blocchi con spaziatura obiettivo di 25 secondi. È un valore predefinito del wallet, configurabile per nodo, e una transazione può essere costruita senza alcuna scadenza impostando il campo a zero.

Quindi il problema del tempo è già risolvibile, almeno dove il wallet espone l'impostazione. Il confine di upgrade non lo è. Un vault potrebbe dare ai suoi membri una settimana per firmare e perdere comunque la transazione nel momento in cui il branch ID cambia. La richiesta di Gorgonha riguardava l'opt-out appena proposto da nuttycom, così che un gruppo potesse raccogliere firme nell'arco di ore o giorni a proprio rischio.

Tre vie d'uscita, ognuna con un rovescio

Rimuovere l'impegno sul branch ID. È la proposta originale di ValarDragon. str4d, ingegnere di Electric Coin Company (ECC), ha risposto che la replay protection era un requisito vincolante da parte di exchange e altri attori dell'ecosistema quando ZIP 200 fu scritto, quindi ogni rimozione necessita di un meccanismo sostitutivo, idealmente uno che copra anche i fork ostili creati unicamente per disturbare la main chain.

Mantenerlo come predefinito e consentire agli utenti di escludersi. nuttycom, anch'esso di ECC, ha proposto varianti di firma sotto ZIP 248 che saltano sia il branch ID sia l'altezza di scadenza. Gli utenti che le scelgono rinunciano a una parte della replay protection e ottengono transazioni che sopravvivono a un upgrade. L'algoritmo esistente, che secondo nuttycom funziona bene per la grande maggioranza delle transazioni, resterebbe il valore predefinito sicuro. str4d aveva già osservato che una simile variante sarebbe facile da definire una volta attivo ZIP 248.

Chiedersi se ciò risolva qualcosa per i wallet. strahncryptography ha sostenuto che le varianti risolvono la longevità delle transazioni ma non l'obsolescenza: se il branch ID non è hard-coded, l'utente deve fornire quello corretto, il che riporta lo stesso onere sul software del wallet. La replay protection contro fork amichevoli ha valore, ha scritto, ma i benefici dovrebbero essere valutati.

Il thread non ha risolto il disaccordo. Ciò che ha fatto è restringere la questione a se una variante opt-in valga la pena essere costruita per gli utenti che ne hanno bisogno, e a cosa quegli utenti dovrebbero rinunciare.

Cosa costerebbe l'opt-out

Il rischio di replay è più facile da immaginare con l'upgrade appena avvenuto. Solo per NU7, ZIP 259 ha derogato al consueto requisito che il software dei nodi obsoleto si auto-deprechi prima dell'attivazione, il che significa che gli operatori che non hanno mai aggiornato possono restare online e continuare a seguire un ramo pre-NU7. Una transazione la cui firma non è vincolata a un ramo è esattamente il tipo che potrebbe essere accettata su entrambi.

L'esposizione riguarda l'ambito di un'autorizzazione, non le chiavi che stanno dietro. Una transazione replicata spende gli stessi input su un'altra catena che il firmatario non intendeva mai usare; non consente a nessuno di forgiarne una nuova.

Eliminare l'altezza di scadenza dalla firma ha un secondo effetto: un pagamento autorizzato può restare non confermato finché i suoi input restano non spesi. È la funzionalità che un vault desidera e il rischio che un utente individuale potrebbe non notare.

nuttycom ha anche segnalato una possibile riduzione dell'anonymity set. In un sistema shielded, la privacy dipende dal fatto che una transazione sia simile a ogni altra; una firmata con una variante raramente usata costituirebbe una folla più piccola in cui nascondersi. Il post non ha quantificato l'effetto, e nessuna variante è stata ancora specificata.

Una firma più longeva non aggiorna un vecchio dispositivo

ZIP 248, il formato di transazione estensibile da cui dipende tutto questo, è ancora una bozza. str4d ha detto che il suo design è stabile da oltre sei mesi e che nella scorsa settimana l'ha aggiornato per le modifiche al consenso distribuite da allora. Non è stato assegnato a un upgrade, e le varianti opt-out non esistono ancora in esso.

Anche una volta che esistano, un hardware wallet o un firmatario offline avrà comunque bisogno di software che comprenda il nuovo formato. ZIP 248 vieta ai wallet di costruire o firmare componenti che non possono interpretare. Il beneficio di compatibilità è reale, ma arriva tramite le release dei wallet, che è il passaggio che secondo strahncryptography continua a fallire.

Né tutto ciò aiuta le transazioni in un formato ritirato. ZIP 259 nota che il divieto NU7 sulle transazioni di versione 4 copre le spese transparent e Sapling oltre a Sprout, e che la rifirma non può salvarle; l'unica soluzione è ricostruire il pagamento in una versione supportata. Coindoo ha coperto la scorsa settimana il caso più difficile, le monete Sprout prive di qualsiasi formato sostitutivo.

Konclave ha anche un suo pezzo incompiuto. La sua issue aperta sulla firma asincrona separa le approvazioni raccolte nel tempo dalla cerimonia interattiva di soglia che il vault esegue oggi. Una transazione che sopravvive a un upgrade rimuove un ostacolo; il flusso di lavoro che consenta ai membri di contribuire man mano che tornano online deve ancora essere scritto e revisionato.

Indicazioni pratiche

Se gestisci un wallet di gruppo:

• L'attivazione è un'altezza di blocco, non una data; lo ZIP di deployment di ogni upgrade la pubblica in anticipo.
• Non aprire un round di firma che potrebbe attraversare quell'altezza.
• Qualsiasi cosa preparata prima dell'attivazione deve essere ricostruita dopo, anche se nessuno l'ha ancora firmata.

Se detieni monete su un vecchio dispositivo:

• Verifica se il suo firmware o la sua app hanno distribuito il supporto NU7 prima di tentare di spendere.
• Una spesa bloccata da un pool supportato è un problema del wallet, non fondi persi.
• Le transazioni di versione 4 salvate prima del 6 novembre non possono essere rifirmate per tornare valide.

L'analisi precedente di Coindoo sui miglioramenti dei pagamenti lato wallet copriva il divario tra la costruzione di una transazione e la sua conferma. Questo thread aggiunge una terza fase in mezzo: mantenere viva l'autorizzazione mentre persone e dispositivi si adeguano.

Prossimi passi

Fine gennaio è l'obiettivo di ValarDragon, non un calendario. str4d ha messo in dubbio nello stesso thread che due mesi e mezzo bastino per il pool Tachyon nella medesima lista, e la voce sul branch ID ha suscitato la piùnetta opposizione tra tutte e sette. Se NU8 uscirà con un opt-out, un sostituto della replay protection o nessuno dei due sarà deciso nel processo ZIP, non sul forum.