Chi segue Bitcoin sul fronte tecnico avrà sicuramente sentito parlare di BIP, ovvero Bitcoin Improvement Proposal. In sostanza, sono delle proposte di aggiornamento del protocollo Bitcoin con l'obbiettivo di introdurre nuove funzionalità. Tra la tante proposte interessanti, oltre a Lightning Network, alle firme di Schnorr e tante altre, troviamo anche MAST.
Esistono diverse proposte riguardo a MAST, ciascuna con differenti meccanismi di implementazione. Proprio per questo motivo, non troviamo un solo BIP ma differenti sigle. Tra di essi cito 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. Al momento non è nota la data dell'impossibile implementazione sulla testnet, ma non dovrebbe mancare molto, visto che si parlava di un generico 2018.
Ma vediamo cos'è e cosa permette di fare MAST.
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. Detto in estrema sintesi, 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'obbiettivo 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.
Va fatta una precisazione. In realtà MAST di per sé non abilita gli Smart Contract. 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 dunque nei blocchi della Blockchain.
Quando Satoshi Nakamoto creo Bitcoin, era possibile utilizzare dei programmi (detti script) che potessero fungere da chiavi pubbliche dinamiche e firme digitali. In questo modo, era possibile 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. Vediamo un esempio, rifacendoci all'esempio originale proposto nel whitepaper. 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 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.
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. 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 ASTs permette di dividere uno script nelle sue singole parti, mentre gli alberi di Merkle consentono di verificare che le singole 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, allora li manda ai fratelli Bob e Charlie (una specie di testamento virtuale), per prima cosa occorre 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 dice che uno Spender deve fornire una prova di Merkle che colleghi la radice di Merkle ad uno dei subscripts. 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.
La prima osservazione che salta all'occhio riguarda il risparmio di dati all'interno dei blocchi. Nell'esempio precedente si è utilizzato uno script piuttosto semplice, ma è possibile anche aggiungere numerosi subscripts 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", ciò vuol dire che 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 classico di Bitcoin è di almeno un ordine di grandezza migliore, specie con script complessi.
Tra gli altri vantaggi, si va a migliorare anche la privacy. Il motivo è piuttosto semplice: vengono inseriti nella blockchain solo i dati essenziali e non quelli superflui.
Nello scenario originale - senza MAST -, avremmo che tutti i dati relativi allo script verrebbero caricati sulla chain. 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 quindi.
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. In ogni caso le idee per migliorare la privacy generale non mancano.
Arriviamo ora al punto più interessante, ovvero la 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. Mentre Segwit ha un limite di 10.000 byte.
Osservando il grafico - che parla da solo -, possiamo notare che tramite MAST si possono avere script molto più complessi (più reiterazioni, subscripts, 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, dato 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.
Come detto in apertura, vi sono vari BIP inerenti a MAST. Principalmente vi sono due modi attraverso i quali MAST può essere aggiunto alla blockchain di Bitcoin.
La prima proposta è il BIP114 di Johnson Lau (jl2012), che utilizza una funzionalità di estensione basata su Segwit. Essa consente agli indirizzi segwit nativi (bech32) di creare una radice di Merkle. Gli spenders dunque, possono selezionare un singolo subscript dalla struttura ad albero.
La seconda proposta è costituita da due BIPs di Mark Friedenbach (maaku), che aumentano la flessibilità del linguaggio Script in modo tale da consentire agli sviluppatori di scrivere script in grado di convalidare automaticamente su MAST. Ciò permetterebbe di usare le Merkle Proof in tutti e tre i tipi di script attualmente supportati da Bitcoin (bare, P2SH e segwit).
Entrambi gli approcci presentano dei compromessi, ma entrambi forniranno i benefici descritti in precedenza. Per l'implementazione basterà attuare un soft-fork.
Vedremo quale delle due verrà implementata.
[sc name="firma"]
[VIA]
Posted from my blog with SteemPress : http://www.cryptominando.it/2018/06/25/mast-bip-privacy-smart-contract-bitcoin/