P2SH & NULL DATA
Aggiungiamo all’analisi delle procedure di verifica che esegue Script per sbloccare le UTXO: P2SH (Pay to Script Hash) e NULL DATA.
La figura rappresenta lo script P2SH che ogni nodo deve eseguire per la verifica della transazione. l’Unlocking script e’ fornito da colui che esegue la transazione come prova di ownership delle UTXO, mentre il Locking script contiene le condizioni necessarie per sbloccarle.
Come spiegato nel precedente articolo questo tipo di script viene utilizzato spesso per la verifica multi signature, pertanto prenderemo tale esempio per analizzarlo nel dettaglio, ma questo non gli preclude l’utilizzo anche per i restanti script gia’ analizzati.
Nell’Unlocking script possiamo vedere: 2 signature, e il Reedem Script che corrisponde alle istruzioni che possiamo trovare in un comune script #P2MS ovvero:
| M
Nell’Locking script come sappiamo contiene le istruzioni di verifica per sbloccare le UTXO necessarie alla formalizzazione della transazione:
- OP_HASH160 che esegue le funzioni di SHA256 e RIPEMD160 sul primo elemento in pop all’interno dello stack.
- Script Hash che corrisponde al risultato delle funzioni di cui sopra del Redeem Script.
- OP_EQUAL che ha il compito di pushare true se due o piu’ elementi sono uguali.
A questo punto procediamo con l’esecuzione:
- push Signature.
- push Signature.
- push Redeem Script = | M
<PubKey> <PubKey> <PubKey> N OP_CHECKMULTISIG|
A questo punto nello stack abbiamo tutto l’Unlocking script. Prima di prendere in considerazione la prima istruzione del Locking script viene fatta una copia esatta dello stack.
Andiamo avanti con il processo di verifica:
- OP_HASH160 prende in pop il Redeem script e gli applica le funzioni #SHA256 e #RIPEMD160.
- push Script Hash nello stack.
- OP_EQUAL confonta lo Script Hash e il l’hash del Redeem script, se sono uquali pusha 1 nello stack.
Non dimentichiamo qualcosa? Ebbene si, c’e’ la copia dello stack fatta in precedenza contenente l’Unlocking script, che tuttavia, non necessita’ di un ulteriore locking in quanto le istruzioni per la verifica sono gia’ presenti. Pertanto vengono eseguite le istruzioni come per un comune #P2MS e solo a quel punto la transazione e’ davvero verificata.
Vi chiederete qual e’ il valore aggiunto di questa variante di script…
Semplice, quando una transazione necessita di un Locking script complesso per essere verificata, e’ molto piu’ performante eseguire il controllo sull’hash di quello script, e non in modo deserializzato istruzione per istruzione.
Passiamo al fatidico NULL DATA
NULL DATA viene utilizzato generalmente per archiviare dati all’interno della blockchain. Depositare dati arbitrari su blockchain non e’ il massimo, ma nel momento in cui ce ne fosse la necessita’ e’ buona prassi utilizzare questo tipo di script in quanto evita il proliferare di UTXO su Level DB con un Locking script che di fatto non puo’ essere sbloccato, e quindi l’importo che ne contiene non e’ spendibile.
Come vediamo in figura l’utente non deve fornire nessun Locking script ,ma si puo’ dire che la verifica della transazione parte dal Locking script eseguendo un unica istruzione: OP_RETURN che termina immediatamente l’esecuzione dello script. dopo tale istruzione ci puo’ essere un set di byte arbitrario.
Una transazione verificata con script NULL DATA per essere inoltrata in broadcast puo’ avere un solo set di byte, altrimenti risulta non valida.
Tutto questo per evitare l’appesantire del db contenete le UTXO che ogni nodo ha in memoria, evitando cosi uno sforzo inutile di risorse come la RAM dei nodi.
