Taproot sta arrivando su Bitcoin: come funziona, la sua storia e le sue implicazioni

Le firme Taproot e Schnorr saranno attive su Bitcoin al blocco 709,632. Questo sarà un enorme risultato fondamentale su cui continuare a costruire nel futuro. Sono passati quattro anni da quando Segregated Witness è entrato in rete sulla rete, il nostro ultimo importante aggiornamento del protocollo. È lungo quanto un ciclo di dimezzamento!

Pensaci. Quattro anni dalla messa in funzione di SegWit alla messa in funzione di Taproot. Pazienza lenta e metodica, come dovrebbe essere. Ma la storia di Taproot/Schnorr risale a molto più tempo fa.

La storia del fittone

Alcuni che sono qui da un po' potrebbero trovarlo ironico, ma la prima menzione delle firme Schnorr di cui sono a conoscenza è stata in realtà da Mike Hearn, ex sviluppatore di Bitcoin Core diventato costruttore di blockchain aziendali. Nel 2012, lui cresciuto l'idea di una nuova curva crittografica in relazione alla verifica batch delle firme per rendere meno costosa dal punto di vista computazionale la validazione dei nodi. In definitiva, lo schema che proponeva dipendeva dalle firme di Schnorr.

Adam Back stava parlando di ingenuo schemi per creare indirizzi multisig che assomigliavano a quelli singlesig nel 2014, utilizzando le firme Schnorr. Anche Gavin Andresen era presente Schnorr invece dell'ECDSA nella sua lista dei desideri dei cambiamenti che apporterebbe a Bitcoin se potesse agitare una bacchetta magica.

Sin dagli albori di Bitcoin, la maggior parte degli sviluppatori attivamente coinvolti in Bitcoin Core hanno voluto le firme Schnorr, e c'è sempre stato un consenso piuttosto solido sulla loro superiorità rispetto alle firme ECDSA. Si potrebbe infatti sostenere che l’ECDSA sia stato creato appositamente perché lo schema di firma Schnorr era brevettato e c’era un enorme bisogno di uno schema di firma crittografica open source non gravato da brevetti.

Schnorr è molto più efficiente e facilmente manipolabile (è possibile aggiungere, sottrarre, ecc. dalle firme e, se eseguito correttamente, può comunque lasciare agli utenti firme valide quando dovrebbero averle) rispetto a ECDSA. Nel corso degli anni, l'utilizzo dell'ECDSA è stato una questione di necessità piuttosto che di desiderio nella maggior parte delle applicazioni crittografiche.

Merkelized Abstract Syntax Trees (MAST), la metà Taproot di questo prossimo aggiornamento Taproot, ha una storia di lunga data simile. Non riesco a trovare la citazione, ma ricordo abbastanza chiaramente di aver visto quella frase lanciata da persone come Peter Todd su Bitcointalk.org intorno al 2013 o 2014.

L'originale BIP per MAST è stata proposta da Johnson Lau nel 2016. Questa proposta ha visto anche alcune attività intorno al 2017 quando Mark Friedenbach, BTCDrak e Kalle Alm l'hanno divisa in due BIP separati (116 ed 117) e ampliato la proposta originale di Lau.

I MAST rimasero in un limbo per l'anno successivo finché Greg Maxwell non ebbe l'idea iniziale di Taproot e pubblicato alla mailing list bitcoin-dev. La sua intuizione chiave era che in ogni caso contrattuale tra più partecipanti a cui riusciva a pensare, c'era un "risultato ottimale" in cui il contratto poteva essere risolto da tutti semplicemente firmando il risultato appropriato invece di imporre il risultato con script e transazioni più avanzati. Questa è l'affermazione fondamentale su cui si basa Taproot, ovvero la modifica dell'albero MAST in una chiave regolare di livello superiore che può essere spesa senza rivelare se esiste un albero Merkle di altre condizioni di spesa.

L'ultimo breve tratto di questa lezione di storia inizia con l'annuncio di Pieter Wiulle progetti di PIF per Schnorr e Taproot insieme alla mailing list il 6 maggio 2019. Entro gennaio 2020, questo è stato formalmente finalizzato in PIF 340, 341 e 342. Da questo punto in poi, si è trattato solo di tanti piccoli dettagli a livello di implementazione, un periodo di revisione e poi il lungo lavoro battaglia sui meccanismi di attivazione. Questo ci porta ad ora, poco prima dell’attivazione.

L'importanza delle firme Schnorr

Allora, qual è il problema con le firme Schnorr? Bene, per iniziare, riducono le transazioni. Una firma ECDSA ha solitamente una dimensione di circa 72 byte per una singola firma in una transazione. Le firme Schnorr arrivano a un massimo di 64 byte per firma. Si tratta di un risparmio di circa il 12% in termini di dimensioni rispetto all'ECDSA per ogni firma Schnorr. Questo è sia un vantaggio diretto per la persona che utilizza Schnorr che pagherà meno in commissioni rispetto a un utente ECDSA, ma è anche un vantaggio diretto per le persone che non utilizzano Schnorr richiedendo che vengano archiviati leggermente meno dati nella blockchain per elaborare e convalidare Schnorr di qualcun altro firme.

Archiviare meno dati è sempre positivo, ma ciò che è ancora meglio è aumentare l'efficienza della convalida dei dati da archiviare. Una delle proprietà interessanti di Schnorr, la linearità della matematica dietro di esso, consente anche una proprietà interessante che desideri nei dati Bitcoin: la convalida batch. Quando il tuo nodo riceve un blocco dalla rete, analizza ogni singola transazione e convalida ciascuna firma una per una.

Questo è uno dei motivi principali per cui la convalida dei blocchi consuma molta potenza della CPU. Le firme di Schnorr possono essere raggruppate insieme e convalidate matematicamente contemporaneamente, un po' come metterle insieme ed eseguire un'operazione matematica invece di un gruppo di singole operazioni. Quindi, più firme Schnorr ci sono, maggiore sarà il risparmio computazionale. Questa è una vittoria enorme per la rete.

Un altro enorme miglioramento apportato da Schnorr riguarda gli script multifirma. Ogni indirizzo multisig deve rivelare esplicitamente tutte le singole chiavi pubbliche coinvolte in uno script multisig al momento della spesa e deve essere fornita una firma per ogni chiave coinvolta nel processo di spesa. Con le proprietà matematiche di Schnorr, si apre la porta a MuSig, uno standard multifirma. Puoi semplicemente aggiungere insieme le chiavi e ottenere un'unica chiave pubblica che le condivisioni della chiave privata di tutti possono firmare utilizzando i nuovi protocolli di firma. Jonas Nick di Blockstream confrontato MuSig2 impiega due minuti per un milione partecipanti in un indirizzo multisig da firmare. Il miglioramento della scalabilità degli script multifirma non può essere sottovalutato.

Questo enorme balzo in avanti per gli script multifirma ha anche un’enorme implicazione per il profilo della privacy e il costo di numerose applicazioni basate su Bitcoin. I canali Lightning basati su MuSig ora possono fondersi con l'intero set di anonimato degli UTXO Schnorr/Taproot sulla catena perché nessuno sarà più in grado di distinguere il fatto che sono un output multisig due su due.

Si fonderanno e sembreranno proprio come un unico script di firma. La stessa cosa vale per qualsiasi UTXO multisig in generale. Ciò avrà molte implicazioni per le persone che utilizzano script multifirma per proteggere meglio il proprio cold storage con un modello di sicurezza e ripristino più robusto rispetto a uno script a firma singola.

In primo luogo, non sarà ovvio che stanno utilizzando una configurazione multisig osservando la blockchain, quindi questo, come nel caso di Lightning, li farà fondere con tutto il resto. Una vittoria chiave, tuttavia, riguarda l’aspetto economico: l’utilizzo della multifirma in questo momento richiede la fornitura di una firma separata per ogni chiave coinvolta nell’eventuale spesa di un UTXO. Con Schnorr/MuSig, le cose saranno compresse in un'unica firma per la singola chiave pubblica combinata, il che significa che spendere UTXO multisig utilizzando MuSig diventerà molto più economico poiché sta inviando meno dati alla blockchain.

Un'ultima cosa interessante che fanno le firme Schnorr è semplificare drasticamente l'implementazione delle firme dell'adattatore. Pensa a una firma dell'adattatore "crittografata" da un valore che è stato aggiunto o sottratto da una firma valida. Non è valido finché non si inverte l'operazione matematica o lo si “decifra” con la “chiave” utilizzata per manipolarlo. Questo è possibile con ECDSA, ma poiché la matematica non è lineare rispetto a Schnorr, è relativamente complicato e ci sono molti problemi di sicurezza da considerare nell'implementarlo.

A causa delle proprietà lineari di Schnorr, tuttavia, la firma di un adattatore è semplice come prendere un singolo (ad esempio il numero 9,300,030) e sottrarre un valore da esso (ad esempio 30). Una volta che la parte che detiene la firma dell'adattatore apprende il valore sottratto, può semplicemente aggiungerlo nuovamente e Ecco, hanno di nuovo una firma valida.

Le implicazioni del fittone

Come discusso poco sopra, Taproot in realtà è essenzialmente solo MAST, tranne che invece di funzionare come P2SH (dove si esegue l'hashing dello script o, nel caso di MAST, la radice Merkle della parte superiore dell'albero dello script), si "modifica" un Chiave pubblica Schnorr dalla radice dell'albero Merkle.

Il tweaking funziona grazie alle proprietà lineari di Schnorr: quando “modifichi” una chiave pubblica con una radice Merkle (aggiungi quella radice Merkle alla chiave pubblica), puoi semplicemente aggiungere la radice Merkle alla chiave privata originale e generare la chiave di spesa per la nuova chiave pubblica ottimizzata. Cioè, aggiungi la stessa cosa sia alla chiave pubblica che a quella privata e sono ancora una coppia di chiavi valida. Ciò nasconde l'esistenza di un albero MAST, a meno che non ne venga utilizzato un ramo, ma fondamentalmente è pur sempre solo un albero MAST, solo uno a cui è dedicato in modo più efficiente e privato.

La capacità di impegnarsi in diversi script di spesa in un albero Merkle e rivelare solo lo script utilizzato è un enorme vantaggio in termini di scalabilità in termini di complessità del contratto intelligente che è possibile costruire su Bitcoin.

Proprio come la dimensione del blocco limita il numero di transazioni per blocco, esiste un limite di limitazione della dimensione della transazione di 100 kilobyte. L'unica differenza è che invece di essere una regola di consenso, è una regola politica. Ciò significa che un minatore può estrarre una transazione più grande di 100 kilobyte, ma per impostazione predefinita, nessun nodo sulla rete inoltrerà in primo luogo una transazione più grande di quella al minatore.

Ciò limita intrinsecamente la dimensione dello script utilizzato per bloccare un Bitcoin UTXO. Anche con P2SH, dove UTXO è bloccato su un hash dello script che non viene rivelato finché non lo spendi, alla fine devi comunque rivelare lo script completo al momento del trascorrere del tempo. Taproot aumenta questo limite di scalabilità dello script non richiedendoti di rivelare l'intero script quando lo usi. Invece di limitare la dimensione totale di tutti i modi in cui puoi spendere UTXO al limite della dimensione della transazione, devi solo assicurarti che ogni singolo modo in cui puoi spendere un Taproot UTXO rispetti questa limitazione.

Ci sono anche molti vantaggi in termini di privacy offerti da Taproot. Uno dei grandi vantaggi di un albero MAST è la capacità di creare tutti i tipi di situazioni condizionali in cui le monete possono essere spese da altre parti.

Immagina cose come programmi di eredità in cui dopo circa un anno i tuoi figli possono spendere le tue monete, o nel caso in cui ti rifiuti di firmare, tua moglie e un avvocato hanno un potenziale percorso per recuperare le monete. Nulla di queste condizioni di spesa viene rivelato al pubblico a meno che non vengano effettivamente utilizzate. Questo duplice processo fornisce una negabilità plausibile per le altre parti coinvolte in diversi rami di spesa che costruisci riguardo al loro coinvolgimento in quell'UTXO, oltre a proteggerli da un ladro o un aggressore che li prende di mira preventivamente sapendo che hanno un certo grado di controllo sui loro UTXO del bersaglio.

Anche a livello tecnico, Taproot è stato progettato relativamente bene. Chiunque legga e abbia familiarità con Testimone Segregato a un livello profondo dovrebbe avere familiarità con la versione del testimone.

Quando è stato implementato il Segregated Witness, è stata creata la nuova sezione “testimone” di una transazione in cui venivano spostati i dati della firma. I dati testimone avevano un flag di versione in modo che potessero essere aggiornati a nuove funzionalità senza dover utilizzare OP_CODE non definiti sul livello base per nuove funzionalità.

Questo è in realtà il modo in cui sono stati implementati Taproot/Schnorr. Le transazioni testimone segregate utilizzano la versione testimone zero. Quando Taproot/Schnorr sarà presto attivo, utilizzeranno la nuova versione testimone per distinguerle dalle transazioni Segregate Witness precedenti. Allo stesso modo in cui SegWit ha introdotto le versioni testimone, Taproot introduce la "versione tapleaf" per i tapscript utilizzati negli alberi MAST per UTXO che utilizzano Taproot. Ciò non solo consente agli script nascosti in MAST di aggiornarsi senza utilizzare nuovi OP_CODE sul livello base, ma anche senza dover aggiornare nemmeno le versioni testimone! Pertanto Taproot è stato progettato per essere il più efficiente possibile per gli aggiornamenti futuri senza limitare altri aggiornamenti non correlati al protocollo.

Taproot porterà molti casi d'uso diversi. Per iniziare, tutte le clausole non cooperative in un canale Lightning, come le chiavi di penalità o i timelock per consentirne l'utilizzo, possono essere sepolte sotto un MAST con Taproot. Nessuno saprà mai della loro esistenza a meno che non debbano essere utilizzati, oscurando ulteriormente quali UTXO siano effettivamente canali Lightning o meno.

Gli schemi di ereditarietà sono un altro caso d'uso. Immagina un albero a fittone strutturato in modo che dopo sei mesi senza spostare i tuoi soldi, tutta la tua famiglia possa riunirsi e spendere l'UTXO come preferisce. Poi, sei mesi dopo, tutti meno una persona possono spenderli (quindi immagina se avessi tua moglie, due figli e i genitori come detentori delle chiavi, quindi immagina che dopo i sei mesi extra, tua moglie, un figlio e i genitori possano firmare , oppure i tuoi due figli e i tuoi genitori possono firmare senza tua moglie, e così via).

Poi, sei mesi dopo, tutti meno due persone potranno spenderlo. Alla fine, potrebbe ridursi a una sola persona con l'aiuto di un avvocato (per assicurarsi che non si verifichino imbrogli) in grado di spendere l'UTXO.

Oppure, cosa succede se utilizzi multisig per proteggere il tuo cold storage, ma hai solo un posto che consideri sicuro e prevedibile a lungo termine? Potresti creare un MAST in cui alla fine, dopo alcuni anni, la chiave in quel luogo sicuro può spendere quelle monete da sola, nel caso in cui altre chiavi vengano perse o distrutte, ma senza mettere immediatamente le tue monete a rischio di furto nel presente se ciò una chiave è stata compromessa.

Si tratta di un aggiornamento straordinario e completo di Bitcoin che è stato probabilmente in lavorazione fin quasi dalla nascita del Bitcoin stesso, non solo negli ultimi anni in cui i dettagli di implementazione effettivi sono stati elaborati e implementati.

È davvero una vittoria in così tanti modi per la scalabilità e l'utilità del protocollo Bitcoin che è difficile da trasmettere a causa di quanto sottili e "poco sexy" siano alcuni di essi. Ma ciò non toglie nulla alla vittoria. Quindi tutti allacciati e pronti a giocare con i nuovi giocattoli che dovremo usare presto, perché Taproot sta arrivando!

Questo è un guest post di Shinobi. Le opinioni espresse sono interamente proprie e non riflettono necessariamente quelle di BTC Inc o Bitcoin Magazine.

Fonte: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer