Read this article in the English version here.

Bitcoin ha cambiato il modo di concepire il denaro e non solo quello. Ma come migliorare una tecnologia di per sé già disruptive per renderla ancora più rivoluzionaria?

Lo spiega Giacomo Zucco, founder di BHB Network nel presentare il nuovo progetto al quale sta lavorando, vale a dire il protocollo RGB.

Già qualche mese fa, intervistato da Cryptonomist durante la conferenza MJAC di Londra, Zucco aveva accennato al progetto, ma ora approfondiamo la questione.

Il 5 luglio scorso, infatti, Zucco ha presentato ufficialmente il protocollo RBG durante la conferenza di Lisbona.

Che cos’è esattamente il protocollo RGB? Cosa può significare per Bitcoin?

È un tentativo di coordinare e stimolare la comunità Bitcoin più seria e credibile attorno al tema degli asset digitali Bitcoin-based, tema che in passato è stato più che altro appannaggio di ambiti poco seri, sia a livello di fondamenta tecnologiche che di fondamenta economiche, con alcune escursioni in ambito Bitcoin che hanno avuto poco seguito e poco successo. È una proposta per arrivare a uno standard e a una serie di best practices su queste tematiche, partendo dal rilancio della vecchia idea di Colored Coin, questa volta però facendo perno sulla integrazione nativa di Lightning Network e sull’architettura Client-Side-Validation, ideata da Peter Todd. Il protocollo consiste, inoltre, in una serie di specifiche che sostanziano questa proposta e di librerie Rust che la implementano.

Come è nata l’idea? Con chi stai lavorando al progetto?

Il progetto è aperto a tutta la community Bitcoin e, proprio in questi giorni, dopo la presentazione alla conferenza Building on Bitcoin, stiamo ricevendo molti feedback da sviluppatori attivi su Lightning Network, così come da altri impegnati su altri progetti relativi agli asset Bitcoin-based, come Counterparty e Confidential Assets, anche per cercare di massimizzare sinergie, convergenze e interoperabilità. Il progetto però nasce, ed è al momento “spinto” e coordinato, dalla non-profit BHB Network, è sponsorizzato da Blockchainlab Switzerland SAGL e da alcuni suoi clienti. L’idea originale arriva proprio da uno di questi clienti, la Digital Identity, che aveva commissionato a Blockchainlab una consulenza in proposito quasi un anno fa. Da un primo brainstorming tra gli sviluppatori di Blockchainlab e alcuni Resident Expert indipendenti di BHB Network, in particolare mi riferisco a Peter Todd e Riccardo Casatta. L’idea ha iniziato a prendere forma. L’influenza principale che ha prevalso sull’architettura generale è quella di Peter Todd, visto che seguiremo il suo approccio, noto come “ClientSideValidation”, e tenuto conto che lui stesso sta sviluppando in questi mesi un’ulteriore estensione chiamata Proofmarshal. Ma anche l’avvento di Lightning Network ha avuto un impatto fondamentale, con molti dei developer principali che hanno dato suggerimenti e contributi, soprattutto Christian Decker. Il tipo di commitment innovativo che utilizziamo, chiamato “pay-to-contract”, è stato inserito soprattutto con l’aiuto di Leonardo Comandini, di Eternity Wall/Open Timestamps.

Puoi aggiungere qualcosa sul team?

Ad oggi, gran parte del lavoro di revisione del design, di concretizzazione delle specifiche e di sviluppo del codice vero e proprio viene svolto dal bravissimo e giovanissimo Alekos Filini, nostro sviluppatore messo a disposizione full time da Blockchainlab Switzerland sul progetto, coadiuvato da altri sviluppatori Blockchainlab come Isidoro Ghezzi e Gianluca Mazza. Abbiamo comunque ricevuto già contributi da altri soggetti, tra cui le startup italiane Inbitcoin e Chainside e molti developer internazionali. Io per ora sto fungendo un po’ da testimonial del progetto, oltre ad essere stato il suo promotore iniziale e avere influito sulle scelte ad alto livello.

Infine, la repository GitHub è mantenuta da Alekos, che si occuperà di tenere ordine nel progetto, che essendo aperto dovrà gestire stimoli, suggerimenti e contributi tra i più disparati.

Qual è l’obiettivo principale? Soppiantare Ethereum?

L’obiettivo principale è quello di offrire ai possibili casi d’uso interessanti per il mercato di “asset su Bitcoin” uno standard sensato, il più possibile scalabile e rispettoso della privacy, che faccia leva quanto più possibile sui punti di forza del protocollo Bitcoin sottostante, ma allo stesso tempo eviti di appesantirlo o di metterlo a repentaglio, e si liberi dei vincoli di Bitcoin quando questi non sono necessari.

Vogliamo offrire uno standard che possa garantire le tipiche feature ricercate dal mercato nei Bitcoin-based assets (trasparenza, indipendenza dall’issuer, apertura e scalabilità sociale, ecc.), evitando quanto possibile gli svantaggi degli esperimenti precedenti: ridotta privacy, ridotta scalabilità, ridotta interoperabilità, incompatibilità con le nuove evoluzioni di Bitcoin.

Un obiettivo è anche quello di sperimentare nuove architetture, come la Client Side Validation e Proofmarshal, e indagare le potenzialità e i limiti di Lightning Network, di cui RGB eredita molti vantaggi e anche molte sfide, come per esempio la ricezione di asset da parte di utenti offline. Ethereum e ERC20 sono a nostro parere pessimi standard, che verranno soppiantati indipendentemente dai nostri sforzi, ma vorremmo essere in grado di fornire una buona alternativa da indicare.

Molti developer e Bitcoin Maximalist hanno espresso il loro supporto al progetto. Qual è il feedback della community?

Per ora devo dire ottimo. Lo scetticismo della community Bitcoin agli esperimenti di questo tipo, specie nella sua componente “maximalist” di cui mi sento parte, deriva anche da alcuni grossi problemi che durante l’ideazione di RGB abbiamo tentato di affrontare onestamente e di mitigare, se non addirittura risolvere. A differenza di tentativi precedenti, il design di RGB non crea un conflitto di interessi tra le risorse scarse dei nodi Bitcoin (blockspace, bandwidth) e le risorse richieste dagli asset per essere emessi e trasportati. Il rapporto tra RGB e Bitcoin è a mio parere più equilibrato, armonioso e “rispettoso” di quanto non fosse con precedenti esperimenti in questo campo. Inoltre credo di avere avuto qualche merito nell’illustrare a livello diciamo così “filosofico” l’utilità e l’opportunità di uno sforzo come questo. A Lisbona abbiamo avuto l’endorsement entusiasta di molti nomi importanti, almeno sull’idea, sull’impianto generale e sugli scopi. Ora l’obiettivo è raggiungere il maggiore consenso possibile sulle specifiche e, a partire da quelle, riscrivere interamente il codice con qualità da produzione e cogliendo tutti i feedback del caso.

Quali le tempistiche della realizzazione? Su quali casi d’uso volete concentrarvi?

Dai primi brainstorming dell’anno scorso, fino alla prima Proof of Concept in Python sviluppata internamente a Blockchainlab, sono passati diversi mesi. Ora però il quadro generale è decisamente definito e sono improbabili sconvolgimenti ulteriori. Prevediamo un lavoro di altri due mesi circa per finalizzare la formalizzazione e la revisione delle specifiche a livello di community, poi almeno un semestre per passare dalla implementazione in Rust all’effettiva integrazione in qualche wallet a livello di produzione. I casi d’uso che ci interessano di più sono quelli, abbastanza realistici già oggi, dei “collectible” digitali (vedi per esempio il fenomeno dei “RarePepes” su Counterparty), e quelli ancora un po’ fantascientifici degli “smart right” automatici indipendenti dall’issuer e dalla regolamentazione (vedi per esempio il token per la futura DAO del progetto Bisq). Ci sono poi casi interessanti di token, diciamo così, semi-regolamentati, che possono essere utili come rappresentazione di moneta fiat e quindi  come come ponte per l’adozione di Bitcoin (vedi per esempio il “dollaro” di Tether).