RGB magic: contratti lato client su Bitcoin

Tradotto dall’originale di Federico Tenga - Pubblicato il 22 nov 2022

Il termine "smart contracts" è precedente all'invenzione della blockchain e dello stesso Bitcoin. La sua prima menzione si trova in un articolo del 1994 di Nick Szabo, che definiva gli smart contract come un "protocollo di transazione computerizzato che esegue i termini di un contratto". Mentre secondo questa definizione Bitcoin, grazie al suo linguaggio di scripting, supportava i contratti intelligenti fin dal primo blocco, il termine è stato reso popolare solo in seguito dai promotori di Ethereum, che hanno stravolto la definizione originale come "codice che viene eseguito in modo ridondante da tutti i nodi in una rete di consenso globale".

Se da un lato delegare l'esecuzione del codice a una rete di consenso globale presenta dei vantaggi (ad esempio, è facile distribuire contratti non consentiti, come i popolari market maker automatizzati), dall'altro questo design presenta un grave difetto: la mancanza di scalabilità (e di privacy). Se ogni nodo di una rete deve eseguire in modo ridondante lo stesso codice, la quantità di codice che può essere effettivamente eseguita senza aumentare eccessivamente il costo di gestione di un nodo (e quindi preservare la decentralizzazione) rimane scarsa, il che significa che solo un piccolo numero di contratti può essere eseguito.

Ma cosa succederebbe se potessimo progettare un sistema in cui i termini del contratto sono eseguiti e convalidati solo dalle parti coinvolte, anziché da tutti i membri della rete? Immaginiamo l'esempio di una società che vuole emettere azioni. Invece di pubblicare il contratto di emissione pubblicamente su un libro mastro globale e di utilizzare tale libro mastro per tracciare tutti i futuri trasferimenti di proprietà, potrebbe semplicemente emettere le azioni privatamente e passare agli acquirenti il diritto di trasferirle ulteriormente. Quindi, il diritto di trasferire la proprietà può essere trasmesso a ogni nuovo proprietario come se fosse una modifica del contratto di emissione originale. In questo modo, ogni proprietario può verificare autonomamente che le azioni ricevute siano autentiche, leggendo il contratto originale e verificando che tutta la storia degli emendamenti che hanno spostato le azioni sia conforme alle regole stabilite nel contratto originale.

In realtà non si tratta di una novità, ma dello stesso meccanismo che veniva utilizzato per il trasferimento di proprietà prima che si diffondessero i registri pubblici. Nel Regno Unito, ad esempio, fino agli anni '90 non era obbligatorio registrare una proprietà quando veniva trasferita. Ciò significa che ancora oggi oltre il 15% dei terreni in Inghilterra e Galles non è registrato. Se state acquistando una proprietà non registrata, invece di verificare su un registro se il venditore è il vero proprietario, dovrete verificare una catena ininterrotta di proprietà risalente ad almeno 15 anni fa (un periodo considerato abbastanza lungo per presumere che il venditore abbia un titolo sufficiente sulla proprietà). In questo modo, dovrete assicurarvi che ogni trasferimento di proprietà sia stato effettuato correttamente e che eventuali ipoteche utilizzate per transazioni precedenti siano state interamente pagate. Questo modello ha il vantaggio di migliorare la privacy sulla proprietà e di non dover dipendere dal gestore del catasto pubblico. D'altro canto, rende la verifica della proprietà del venditore molto più complicata per l'acquirente.

Come si può migliorare il trasferimento di proprietà non registrate? Innanzitutto, rendendolo un processo digitalizzato. Se esiste un codice che può essere eseguito da un computer per verificare che tutta la storia dei trasferimenti di proprietà sia conforme alle norme contrattuali originali, la compravendita diventa molto più veloce ed economica.

In secondo luogo, per evitare il rischio che il venditore spenda due volte il proprio bene, è necessario implementare un sistema di prova della pubblicazione. Ad esempio, si potrebbe implementare una regola secondo cui ogni trasferimento di proprietà deve essere impegnato in un punto predefinito di un giornale noto (ad esempio, mettere l'hash del trasferimento di proprietà nell'angolo superiore destro della prima pagina del New York Times). Poiché non è possibile collocare l'hash di un trasferimento nello stesso posto due volte, questo impedisce i tentativi di doppio passaggio. Tuttavia, utilizzare un giornale famoso per questo scopo presenta alcuni svantaggi:

1. Bisogna acquistare molti giornali per il processo di verifica. Non è molto pratico.
2. Ogni contratto ha bisogno di un proprio spazio nel giornale. Non è molto scalabile.
3. L'editore del giornale può facilmente censurare o, peggio ancora, simulare una doppia spesa inserendo un hash casuale nel vostro slot, facendo credere a qualsiasi potenziale acquirente del vostro bene che sia già stato venduto in precedenza e scoraggiandolo dall'acquistarlo. Non è molto affidabile.

Per questi motivi, è necessario trovare un posto migliore per pubblicare i trasferimenti di prova della proprietà. E quale opzione migliore della blockchain di Bitcoin, un libro mastro pubblico già affermato e affidabile, con forti incentivi a mantenerlo resistente alla censura e decentralizzato?

Se utilizziamo Bitcoin, non dovremmo specificare un punto fisso nel blocco in cui deve avvenire l'impegno a trasferire la proprietà (ad esempio nella prima transazione) perché, proprio come nel caso dell'editore del New York Times, il minatore potrebbe sbagliare. Un approccio migliore è quello di inserire l'impegno in una transazione Bitcoin predefinita, più precisamente in una transazione che ha origine da un output di transazione non speso (UTXO) a cui è collegata la proprietà dell'asset da emettere. Il legame tra un asset e un UTXO bitcoin può avvenire sia nel contratto che emette l'asset sia in un successivo trasferimento di proprietà, rendendo ogni volta l'UTXO di destinazione il controllore dell'asset trasferito. In questo modo, abbiamo definito chiaramente dove dovrebbe essere l'obbligo di trasferire la proprietà (cioè nella transazione Bitcoin originata da un particolare UTXO). Chiunque gestisca un nodo Bitcoin può verificare in modo indipendente gli impegni e né i minatori né qualsiasi altra entità sono in grado di censurare o interferire in alcun modo con il trasferimento dell'asset.

Poiché sulla blockchain Bitcoin pubblichiamo solo l'impegno di un trasferimento di proprietà, non il contenuto del trasferimento stesso, il venditore ha bisogno di un canale di comunicazione dedicato per fornire all'acquirente tutte le prove che il trasferimento di proprietà è valido. Questo può essere fatto in vari modi, potenzialmente anche stampando le prove e spedendole con un piccione viaggiatore, il che, anche se un po' poco pratico, farebbe comunque il suo lavoro. Ma l'opzione migliore per evitare la censura e le violazioni della privacy è quella di stabilire una comunicazione diretta crittografata peer-to-peer, che rispetto ai piccioni ha anche il vantaggio di essere facilmente integrabile con un software di verifica delle prove ricevute dalla controparte.

Il modello appena descritto per i contratti convalidati lato client e i trasferimenti di proprietà è esattamente quello che è stato implementato con il protocollo RGB. Con RGB è possibile creare un contratto che definisce i diritti, li assegna a uno o più bitcoin UTXO esistenti e specifica come trasferirne la proprietà. Il contratto può essere creato a partire da un modello, chiamato "schema", in cui il creatore del contratto si limita a modificare i parametri e i diritti di proprietà, come avviene nei contratti legali tradizionali. Attualmente, in RGB esistono due tipi di schemi: uno per l'emissione di token fungibili (RGB20) e un secondo per l'emissione di oggetti da collezione (RGB21), ma in futuro altri schemi potranno essere sviluppati da chiunque in maniera libera da permessi, senza richiedere modifiche a livello di protocollo.

Per fare un esempio più pratico, un emittente di beni fungibili (ad esempio azioni di società, stablecoin, ecc.) può utilizzare il modello di schema RGB20 e creare un contratto che definisca quanti token emetterà, il nome del bene e alcuni metadati aggiuntivi ad esso associati. Può quindi definire quale UTXO di bitcoin ha il diritto di trasferire la proprietà dei token creati e di assegnare altri diritti ad altri UTXO, come il diritto di effettuare un'emissione secondaria o di rinominare l'asset. Ogni cliente che riceve i token creati da questo contratto sarà in grado di verificare il contenuto del contratto Genesi (quello originale, n.d.t.) e di convalidare che qualsiasi trasferimento di proprietà nella storia del token ricevuto abbia rispettato le regole ivi stabilite.

Che cosa possiamo fare oggi in pratica con RGB? Innanzitutto, consente l'emissione e il trasferimento di asset tokenizzati con una migliore scalabilità e privacy rispetto a qualsiasi alternativa esistente. Dal punto di vista della privacy, RGB beneficia del fatto che tutti i dati relativi al trasferimento sono conservati sul lato client, quindi un osservatore della blockchain non può estrarre alcuna informazione sulle attività finanziarie dell'utente (non è nemmeno possibile distinguere una transazione in bitcoin contenente un impegno RGB da una transazione normale); inoltre, il destinatario condivide con il mittente solo UTXO ciechi (cioè l'hash della concomitanza di due bitcoin con un impegno RGB). L'UTXO è un'operazione che non è in grado di garantire la riservatezza del destinatario, ma che è in grado di monitorare le attività future di quest'ultimo. Per aumentare ulteriormente la privacy degli utenti, RGB adotta anche un meccanismo crittografico a prova di bomba per nascondere gli importi nella cronologia dei trasferimenti di asset, in modo che anche i futuri proprietari di asset abbiano una visione offuscata del comportamento finanziario dei precedenti possessori.

Anche in termini di scalabilità, RGB offre alcuni vantaggi. Innanzitutto, la maggior parte dei dati viene mantenuta fuori dalla catena, in quanto la blockchain viene utilizzata solo come livello di impegno, riducendo le commissioni da pagare e facendo sì che ogni client convalidi solo i trasferimenti a cui è interessato invece di tutte le attività di una rete globale. Poiché un trasferimento RGB richiede comunque una transazione in Bitcoin, il risparmio sulle commissioni può sembrare minimo, ma quando si inizia a introdurre il batching delle transazioni può diventare rapidamente enorme. Infatti, è possibile trasferire tutti i token (o, più in generale, i "diritti") associati a un UTXO verso una quantità arbitraria di destinatari con un unico impegno in una singola transazione bitcoin. Supponiamo di essere un fornitore di servizi che effettua pagamenti a più utenti contemporaneamente. Con RGB, potete impegnare in una singola transazione Bitcoin migliaia di trasferimenti a migliaia di utenti che richiedono diversi tipi di beni, rendendo il costo marginale di ogni singolo pagamento assolutamente trascurabile.

Un altro meccanismo di risparmio delle commissioni per gli emittenti di asset di basso valore è che in RGB l'emissione di un asset non richiede il pagamento di commissioni. Questo avviene perché la creazione di un contratto di emissione non necessita di un impegno sulla blockchain. Un contratto definisce semplicemente a quale UTXO già esistente saranno assegnate le nuove attività emesse. Quindi, se siete un artista interessato a creare token da collezione, potete emetterne quanti ne volete gratuitamente e pagare la commissione di transazione in bitcoin solo quando un acquirente si presenta e richiede l'assegnazione del token al suo UTXO.

Inoltre, poiché RGB è costruito sulla base delle transazioni in bitcoin, è anche compatibile con la rete Lightning. Anche se al momento non è ancora stato implementato, sarà possibile creare canali Lightning specifici per le attività e instradare i pagamenti attraverso di essi, in modo simile a come funziona con le normali transazioni Lightning.

Conclusione

RGB è un'innovazione rivoluzionaria che apre a nuovi casi d'uso utilizzando un paradigma completamente nuovo, ma quali sono gli strumenti disponibili per utilizzarlo? Se volete sperimentare il nucleo della tecnologia stessa, dovreste provare direttamente il nodo RGB. Se si vuole costruire applicazioni su RGB senza doversi addentrare nella complessità del protocollo, si può usare la libreria rgb-lib, che fornisce un'interfaccia semplice per gli sviluppatori. Se si vuole solo provare a emettere e trasferire beni, si può giocare con Iris Wallet per Android, il cui codice è anche open source su GitHub. Se volete saperne di più su RGB, potete consultare questo elenco di risorse.

Federico Tenga