Nelle ultime settimane lo sviluppatore Pieter Wuille ha rilasciato i sorgenti di due nuovi BIP per l’implementazione di Schnorr e Taproot su Bitcoin. Quest’ultimo, consiste in una possibile evoluzione di MAST, protocollo volto a migliorare privacy e script di Bitcoin.
Read this article in the English version here.
MAST è un BIP – acronimo di Bitcoin Improvement Proposal – inizialmente proposto dal Dr. Johnson Lau nel 2016.
Esistono diverse proposte riguardo a MAST, ciascuna con differenti meccanismi di implementazione. Proprio per questo motivo, non troviamo un solo BIP ma differenti sigle. Esiste infatti il BIP114, ed il secondo ramo di sviluppo di MAST, alla base dei BIP 116 e 117. Il 117 è stato aggiornato lo scorso febbraio/gennaio 2018, mentre il 114 a settembre 2017.
Summary
Cos’è MAST?
Acronimo di Merkelized Abstract Syntax Trees, tale protocollo deriva dall’unione del Merkle Tree e degli AST, ovvero gli abstract syntax trees. Il merkle tree può essere visto come uno strumento crittografico volto a ridurre l’uso dei dati all’interno di un blocco. Esso permette di confermare se i dati all’interno di un albero Merkle sono veritieri senza doverli per forza riscaricare tutti.
Gli Abstract Syntax Trees (AST), invece, consistono in una serie di algoritmi che dividono un programma o set di dati nelle parti che lo costituiscono con l’obiettivo di comprenderlo e classificarlo più facilmente. Questa suddivisione aiuta ad accedere più velocemente a tutti i dati più importanti, escludendo facilmente quelli superflui.
Combinando gli alberi di Merkle ed AST diventa quindi possibile aggiungere set di dati più complessi alle transazioni che andranno inserite nella blockchain di bitcoin, pur consentendo di ridurre le dimensioni dei dati delle transazioni stesse grazie all’uso delle Merkle Proofs.
Sfruttando questo concetto, infatti, chi effettua transazioni può sostituire i dati inutilizzati della transazione stessa con una merkle proof, così da permettere la riduzione della dimensione delle transazioni, di aumentare la privacy e rendere possibile la creazione degli smart contract molto complessi senza impattare sulla rete.
Occorre fare una precisazione. In realtà MAST di per sé non abilita gli smart contract su Bitcoin. Permette semplicemente, tramite le funzionalità sopra elencate, di ridurre la dimensione dei dati necessari per gli script bitcoin, consentendo dunque di inserire set complessi all’interno delle transazioni e quindi nei blocchi della blockchain.
Il problema degli script Bitcoin
Quando Satoshi Nakamoto creò Bitcoin era possibile utilizzare dei programmi (detti script) che potessero fungere da chiavi pubbliche dinamiche e firme digitali. In questo modo si poteva spendere bitcoin in base al comportamento determinato dai vincoli (un vincolo temporale di spesa ad esempio) imposti nello script stesso. Si trattava di un vero e proprio primo approccio agli smart contract.
Tuttavia, tale approccio presenta alcuni limiti in caso di utilizzi più complessi. L’esempio proposto nel whitepaper riporta:
“Alice vuole spendere i propri bitcoin in qualsiasi momento, ma vuole anche che se entro tre mesi i suoi bitcoin non sono stati spesi, vengano distribuiti ai suoi fratelli Bob e Charlie.”
In questo caso, lo script nel quale viene specificata la policy sopra descritta include non solo la chiave pubblica di Alice (necessaria per verificare la firma dalla sua chiave privata) ma anche una logica condizionale, un timeout e le chiavi pubbliche di Bob e Charlie.
Nell’attuale protocollo Bitcoin, tutti i dati sopra riportati devono venir inseriti sulla blockchain quando i bitcoin di Alice vengono spesi. Vanno però incluse anche le parti dello script che non vengono utilizzate, come le chiavi pubbliche di Bob e Charlie, inutili nel caso in cui sia Alice stessa a spendere i propri bitcoin.
Tutti questi dati inutilizzati aumentano le dimensioni delle transazioni. Non solo, ma riducono anche la privacy divulgando pubblicamente più informazioni del necessario. Inoltre, limitano gli smart contract in funzione della loro dimensione piuttosto che dei costi di convalida delle transazioni.
MAST: una possibile soluzione
Il protocollo MAST cerca di migliorare significativamente la situazione attuale, eliminando la necessità di includere direttamente le parti non utilizzate di uno script sulla blockchain. In questo modo, oltre a ridurre le dimensioni delle transazioni, si migliora la privacy e diventa possibile creare smart contract complessi in massa.
Lo sviluppatore bitcoin Luke-jr scrisse nel novembre 2016:
“L’idea del Merkelized Abstract Syntax Tree (MAST) è quella di utilizzare un albero di Merkle per codificare le operazioni in uno script bitcoin. In questo modo, quando si effettua una spesa, gli utenti possono fornire solo i rami che stanno eseguendo e gli hash che collegano i rami alla radice di Merkle di dimensione fissa. Ciò riduce significativamente la dimensione dello stack, che passa da O(n) a O(log n), dove n è il numero di operazioni”.
In sintesi dunque, MAST sfruttando gli AST permette di dividere uno script nelle sue singole parti, mentre gli alberi di Merkle consentono di verificare che tali parti appartengono ad uno script completo senza dover possedere l’intero codice, che quindi non dovrà essere incluso per intero ogni volta sulla blockchain.
Applicando tale idea all’esempio di prima, ovvero con Alice che può spendere i propri bitcoin quando vuole, ma se per tre mesi non li spende essi vengono mandati ai fratelli Bob e Charlie (una specie di testamento virtuale), occorre per prima cosa creare un albero di Merkle.
La radice di Merkle dell’albero identifica in modo univoco lo script di Alice ed i partecipanti utilizzando solamente 32 byte di dati. Per fare ciò, ogni nodo dell’albero possiede un proprio hash identificativo univoco. Ognuno di questi identificatori viene poi accoppiato all’identificatore di un altro nodo. Viene poi nuovamente generato un hash identificativo univoco, stavolta riferito a quella coppia di nodi. Questo passaggio viene ripetuto fino a quando rimane un solo identificatore, ovvero la radice di Merkle. Esso identifica in modo univoco l’intero insieme in pochi byte di dati, in questo esempio solo 32 Byte.
A questo punto, Alice aggiunge un vincolo in cui impone che uno Spender deve fornire una prova di Merkle che colleghi la radice di Merkle ad uno dei subscript. Tale subscript dovrà restituire il valore “True” per consentire la spesa vera e propria.
Si riesce quindi ad ottenere un significativo risparmio di memoria all’interno delle transazioni, che, sfruttando tale sistema, includeranno solamente lo stretto necessario.
Ottimizzazione dell’uso della blockchain
La prima osservazione che salta all’occhio riguarda il risparmio di dati all’interno dei blocchi. Nell’esempio precedente si è utilizzato uno script Bitcoin piuttosto semplice, ma è possibile anche aggiungere numerosi subscript con nuove condizioni e vincoli. Ne consegue che, sfruttando MAST, si riesce non solo ad avere una notevole riduzione dell’ingombro dei dati, ma anche a consentire la creazione di script sempre più estesi e complessi.
Tramite l’approccio all’albero di Merkle, inoltre, si ottimizza ulteriormente l’uso della memoria, favorendo una miglior riduzione dei dati nel caso d’utilizzo più reale. In parole povere, riferendosi all’esempio di prima inerente al “testamento digitale”, lo scenario più realistico è che Alice continui a spendere i propri bitcoin, perché appunto continua a vivere. Quello pessimistico invece, si ha nel caso in cui Alice muoia, e quindi i propri bitcoin passino ai fratelli.
La struttura ad albero premia – in termini d’uso della memoria – il caso più realistico, ovvero che Alice non muoia (in giallo), consentendole di effettuare le proprie transazioni con il minor uso di memoria rispetto a tutti gli altri casi più improbabili (rosso/viola).
In ogni caso, il vantaggio rispetto al protocollo Bitcoin è di almeno un ordine di grandezza migliore, specie con script complessi.
Più privacy per bitcoin
Tra gli altri vantaggi, si va a migliorare anche la privacy di Bitcoin. Il motivo è piuttosto semplice: vengono inseriti nella blockchain solo i dati essenziali e non quelli superflui.
Nello scenario originale – senza MAST -, tutti i dati relativi allo script verrebbero caricati sulla blockchain. Fra di essi avremmo anche le chiavi pubbliche di Bob e Charlie, quindi un malintenzionato potrebbe risalire a chi erediterà i bitcoin di Alice. Con MAST invece, con le sole informazioni condivise non sarebbe possibile risalire alle condizione imposte ed agli eredi.
Ci sono inoltre anche altri vantaggi in termini di privacy, ma essi prevedono un’adozione di massa di MAST per diventare realmente efficaci. Per evitare infatti che un malintenzionato riconosca l’uso di uno script specifico da parte di Alice, si potrebbe realizzare uno script “di massa” uguale per tutti gli utilizzatori di MAST, con lo scopo di rendere indistinguibili i singoli casi dagli altri.
Ma questo è un caso molto particolare, dovuto non a MAST in sé ma ad una possibile implementazione.
Sul fronte privacy sono stati fatti ulteriori passi avanti con Taproot, una vera e propria evoluzione di MAST che, combinata con le firme di Schnorr, offre un miglioramento tangibile della privacy di Bitcoin.
Script Bitcoin più complessi
La feature più interessante di MAST consiste nella possibilità di creare smart contract (script) sempre più complessi. Ad oggi Bitcoin ha tre diversi limiti di dimensione dei byte utilizzabili ai singoli script a seconda dei vincoli. Vi è un limite di 10.000 byte, aggiunto nel luglio 2010, per gli script Bare. Limite che scende a 520 byte per gli script P2SH. Segwit invece, ha un limite di 10.000 byte.
Osservando il grafico è possibile notare che tramite MAST si possono avere script molto più complessi (più reiterazioni, subscript, condizioni etc) rispetto a quanto sia possibile con gli altri meccanismi. Il tutto rientrando nel limite P2SH.
Ci sono poi altri limiti che si applicano agli script Bitcoin che MAST permette di bypassare, dal momento che non richiede che gli script inutilizzati vengano processati da un full node. Nel complesso, MAST mantiene e migliora notevolmente la scalabilità degli script Bitcoin, ottimizzando al massimo l’uso delle risorse, spostando il grosso del carico della gestione del contratto ai partecipanti stessi, così da influire minimamente sul network.
Quindi il vero risultato di MAST in realtà, non è consentire agli utenti di Bitcoin di creare script più avanzati di prima (si poteva già fare ma usando molte risorse), ma di consentire tale operazione senza appesantire la rete Bitcoin.
Taproot: la possibile implementazione di MAST
Al momento il BIP che ha più probabilità di venir implementato nel protocollo Bitcoin, è quello recentemente proposto da Pieter Wuille, che prevede l’integrazione di MAST nell’evoluzione più recente: Taproot.
Difficile ipotizzare quando avverrà il fork effettivo per l’upgrade di Bitcoin (potrebbe non bastare un soft fork). Tuttavia il recente rilascio su Github dei primissimi codici sorgenti consentirà alla community di controllare e testare i BIP proposti, valutando insieme eventuali modifiche nonché la conferma definitiva per l’upgrade finale.