RGB Magic: contratti lato client su Bitcoin

Questo è un editoriale di opinione di Federico Tenga, collaboratore di lunga data di progetti Bitcoin con esperienza come fondatore, consulente ed educatore di start-up.

Il termine "contratti intelligenti" precede l'invenzione della blockchain e dello stesso Bitcoin. La sua prima menzione è in a Articolo del 1994 di Nick Szabo, che ha definito i contratti intelligenti come un "protocollo di transazione computerizzato che esegue i termini di un contratto". Mentre con questa definizione Bitcoin, grazie al suo linguaggio di scripting, supportava gli smart contract fin dal primo blocco, il termine è stato reso popolare solo in seguito dai promotori di Ethereum, che hanno distorto la definizione originale come "codice eseguito in modo ridondante da tutti i nodi in un consenso globale Rete"

Mentre delegare l'esecuzione del codice a una rete di consenso globale ha dei vantaggi (ad esempio è facile implementare contratti non dovuti, come i market maker comunemente automatizzati), questo design ha un grosso difetto: mancanza di scalabilità (e privacy). Se ogni nodo in 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 esecuzione di un nodo (e quindi preservare il decentramento) rimane scarsa, il che significa che solo un piccolo numero di contratti può essere eseguito.

Ma se potessimo progettare un sistema in cui i termini del contratto sono eseguiti e convalidati solo dalle parti coinvolte, piuttosto che da tutti i membri della rete? Immaginiamo l'esempio di una società che vuole emettere azioni. Invece di pubblicare pubblicamente il contratto di emissione su un libro mastro globale e utilizzare quel libro mastro per tenere traccia di tutti i futuri trasferimenti di proprietà, potrebbe semplicemente emettere le azioni privatamente e trasferire agli acquirenti il ​​diritto di trasferirle ulteriormente. Successivamente, il diritto di trasferire la proprietà può essere trasferito a ciascun nuovo proprietario come se si trattasse di una modifica del contratto di emissione originario. In questo modo ciascun titolare può autonomamente verificare la genuinità delle azioni ricevute, leggendo il contratto originario e verificando che tutta la storia delle modifiche che hanno movimentato le azioni è conforme alle regole previste dal contratto originario.

Questa in realtà non è una novità, è anzi lo stesso meccanismo che veniva utilizzato per trasferire la proprietà prima che diventassero popolari i registri pubblici. Nel Regno Unito, ad esempio, non era obbligatorio registrare un immobile al momento del trasferimento della proprietà fino agli anni '90. Ciò significa che ancora oggi oltre il 15% dei terreni in Inghilterra e Galles non è registrato. Se stai acquistando un immobile non registrato, invece di verificare su un registro se il venditore è il vero proprietario, dovresti verificare una catena di proprietà ininterrotta che risale ad almeno 15 anni (un periodo considerato abbastanza lungo per presumere che il venditore abbia sufficiente titolo di proprietà). In tal modo, è necessario assicurarsi che qualsiasi passaggio di proprietà sia stato eseguito correttamente e che eventuali ipoteche utilizzate per operazioni precedenti siano state interamente estinte. Questo modello ha il vantaggio di una maggiore privacy rispetto alla proprietà e non è necessario fare affidamento sul manutentore del catasto pubblico. D'altra parte, rende la verifica della proprietà del venditore molto più complicata per l'acquirente.

Come si può migliorare il trasferimento di proprietà non registrate? Prima di tutto rendendolo un processo digitalizzato. Se esiste un codice che può essere eseguito da un computer per verificare che tutta la cronologia dei passaggi di proprietà sia conforme alle regole del contratto originale, l'acquisto e la vendita diventano molto più veloci ed economici.

In secondo luogo, per evitare il rischio che il venditore spenda due volte il proprio bene, deve essere implementato un sistema di prova della pubblicazione. Ad esempio, potremmo implementare una regola per cui ogni trasferimento di proprietà deve essere eseguito in un punto predefinito di un noto quotidiano (ad esempio, metti l'hash del trasferimento di proprietà nell'angolo in alto a destra della prima pagina del New York Volte). Dal momento che non è possibile posizionare due volte l'hash di un trasferimento nello stesso posto, ciò impedisce i tentativi di doppia spesa. Tuttavia, utilizzare un giornale famoso per questo scopo presenta alcuni svantaggi:

1. Devi comprare 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 la doppia spesa inserendo un hash casuale nel tuo slot, facendo credere a qualsiasi potenziale acquirente del tuo asset che sia stato venduto prima e scoraggiandolo dall'acquistarlo. Non molto affidabile.

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

Se usiamo Bitcoin, non dovremmo specificare un posto fisso nel blocco in cui deve avvenire l'impegno a trasferire la proprietà (ad esempio nella prima transazione) perché, proprio come con l'editore del New York Times, il minatore potrebbe pasticciare. Un approccio migliore consiste nel collocare l'impegno in una transazione Bitcoin predefinita, più specificamente 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 o nel contratto che emette l'asset o in un successivo passaggio di proprietà, rendendo di volta in volta l'UTXO target il controllore dell'asset trasferito. In questo modo, abbiamo definito chiaramente dove dovrebbe essere l'obbligo di trasferimento della proprietà (ovvero 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 di asset.

Poiché sulla blockchain di Bitcoin pubblichiamo solo un impegno di 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 potrebbe essere fatto in diversi modi, potenzialmente anche stampando le bozze e spedendole con un piccione viaggiatore, che, sebbene un po' poco pratico, farebbe comunque il lavoro. Ma l'opzione migliore per evitare la censura e le violazioni della privacy è stabilire una comunicazione crittografata peer-to-peer diretta, che rispetto ai piccioni ha anche il vantaggio di essere facilmente integrabile con un software per verificare le prove ricevute dalla controparte.

Questo 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 può essere trasferita la loro proprietà. Il contratto può essere creato a partire da un modello, chiamato “schema”, in cui il creatore del contratto si limita a regolare i parametri e i diritti di proprietà, come avviene con i tradizionali contratti legali. Attualmente, ci sono due tipi di schemi in RGB: uno per l'emissione di token fungibili (RGB20) e un secondo per l'emissione di oggetti da collezione (RGB21), ma in futuro chiunque potrà sviluppare più schemi senza autorizzazione senza richiedere modifiche a livello di protocollo.

Per fare un esempio più pratico, un emittente di asset fungibili (ad es. azioni societarie, stablecoin, ecc.) può utilizzare il modello di schema RGB20 e creare un contratto definendo quanti token emetterà, il nome dell'asset e alcuni metadati aggiuntivi associati con esso. Può quindi definire quale bitcoin UTXO ha il diritto di trasferire la proprietà dei token creati e 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 dal presente contratto potrà verificare il contenuto del contratto Genesis e convalidare che qualsiasi trasferimento di proprietà nella storia del token ricevuto abbia rispettato le regole ivi stabilite.

Quindi cosa possiamo fare oggi in pratica con l'RGB? Innanzitutto, consente l'emissione e il trasferimento di risorse tokenizzate con una migliore scalabilità e privacy rispetto a qualsiasi alternativa esistente. Sul fronte della privacy, RGB beneficia del fatto che tutti i dati relativi al trasferimento sono mantenuti lato client, quindi un osservatore blockchain non può estrarre alcuna informazione sulle attività finanziarie dell'utente (non è nemmeno possibile distinguere una transazione bitcoin contenente un impegno RGB da uno regolare), inoltre, il destinatario condivide con il mittente solo l'UTXO in cieco (ovvero l'hash della concatenazione tra l'UTXO in cui desidera ricevere gli asset e un numero casuale) invece dell'UTXO stesso, quindi non è possibile per il pagatore monitorare le attività future del destinatario. Per aumentare ulteriormente la privacy degli utenti, RGB adotta anche il meccanismo crittografico antiproiettile 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 detentori.

In termini di scalabilità, RGB offre anche alcuni vantaggi. Innanzitutto, la maggior parte dei dati viene tenuta off-chain, poiché la blockchain viene utilizzata solo come livello di impegno, riducendo le commissioni che devono essere pagate e il che significa che ogni cliente convalida solo i trasferimenti a cui è interessato invece di tutti i attività di una rete globale. Poiché un trasferimento RGB richiede ancora una transazione Bitcoin, il risparmio sulle commissioni può sembrare minimo, ma quando inizi a introdurre il batch delle transazioni possono diventare rapidamente enormi. È infatti possibile trasferire tutti i token (o, più in generale, i “diritti”) associati a un UTXO verso un numero arbitrario di destinatari con un unico impegno in un'unica transazione bitcoin. Supponiamo che tu sia un fornitore di servizi che effettua pagamenti a più utenti contemporaneamente. Con RGB puoi impegnare in una singola transazione Bitcoin migliaia di trasferimenti a migliaia di utenti che richiedono diversi tipi di asset, rendendo assolutamente irrisorio il costo marginale di ogni singolo pagamento.

Un altro meccanismo di risparmio delle commissioni per gli emittenti di attività di basso valore è che in RGB l'emissione di un'attività non richiede il pagamento di commissioni. Questo accade perché la creazione di un contratto di emissione non deve essere impegnata sulla blockchain. Un contratto definisce semplicemente a quale UTXO già esistente saranno assegnati gli asset di nuova emissione. Quindi, se sei un artista interessato a creare token collezionabili, puoi emetterne quanti ne vuoi gratuitamente e poi pagare la commissione di transazione bitcoin solo quando un acquirente si presenta e richiede che il token venga assegnato al proprio UTXO.

Inoltre, poiché RGB si basa sulle transazioni bitcoin, è anche compatibile con Lightning Network. Sebbene non sia ancora implementato al momento della scrittura, sarà possibile creare canali Lightning specifici per asset 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 strumenti sono disponibili per utilizzarlo? Se vuoi sperimentare il cuore della tecnologia stessa, dovresti provare direttamente il nodo RGB. Se desideri creare applicazioni su RGB senza dover approfondire la complessità del protocollo, puoi utilizzare il file libreria rgb-lib, che fornisce un'interfaccia semplice per gli sviluppatori. Se vuoi solo provare a emettere e trasferire risorse, puoi giocare con Portafoglio Iris per Android, il cui codice è anche open source su GitHub. Se vuoi solo saperne di più su RGB puoi dare un'occhiata questo elenco di risorse.

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