RGB Protocol

Il protocollo "RGB" viene proposto per l'emissione, l'archiviazione e il trasferimento di asset digitali basati su blockchain. Il protocollo mira a fornire uno standard per in modo da superare le principali carenze dei precedenti tentativi. Il protocollo è basato su Bitcoin e ha lo scopo di fornire un livello accettabile di scalabilità, riservatezza e standard.

Motivazione

Digital Assets

C'è un interesse continuo e crescente per le risorse digitali che rappresentano in qualche modo un proxy per titoli (azioni, obbligazioni, depositi, royalties, diritti di voto, IOU per beni fisici, ecc.), Utilità (buoni, coupon, punti fedeltà, gettoni casinò, sconto diritti, pre-vendita di ricevute, alternative di pagamento, ecc.) o da collezione.

I metodi tradizionali di emissione e trasferimento di risorse sono in genere lenti, costosi, inefficienti e presentano molti attriti, sia dal punto di vista tecnologico che da quello regolamentare. Oggigiorno un numero crescente di aziende, start-up, istituti finanziari o anche singoli individui sono disposti a emettere beni digitali in più casi d'uso.

Bitcoin-based (non-bitcoin) Assets?

Mentre i modelli centralizzati e basati sulla fiducia per la gestione delle risorse digitali sono ancora, in molti casi, l'opzione più razionale, c'è un crescente interesse per l'applicazione a questo problema dello stesso tipo di tecnologia "blockchain" che alimenta Bitcoin (un puro protocollo peer-to-peer, decentralizzato, fidato, senza autorizzazione nato per gestire l'omonima valuta digitale).

Gran parte di questo interesse è guidato da ragioni di marketing nel contesto dell'attuale ciclo di hype, in quanto le strategie basate su blockchain risultano spesso inutili (in molti schemi di asset digitali c'è già un inevitabile bisogno di una controparte centrale) e persino dannose (un design blockchain-based è solitamente più costoso, lento, inefficiente e privo di privacy se confrontato con alternative centralizzate esistenti, la sua implementazione è solitamente più complessa, sfidata da problemi di sicurezza nuovi e non ben compresi e richiede competenze non ancora comuni nel mercato, fornendo al contempo "Caratteristiche" che sono spesso indesiderabili per ragioni aziendali e / o normative, come pseudo-anonimato, resistenza alla censura, completa apertura, ecc.). Potrebbero esserci comunque dei motivi legittimi per usare un tale design.

Asset Independence

Una prima serie di motivi potrebbe essere correlata a casi d'uso in cui il valore di mercato (o il valore d'uso) dell'attività è completamente indipendente dall'emittente centralizzato subito dopo il momento dell'emissione. L'esempio più ovvio di questo scenario è quello degli oggetti da collezione digitali: una volta che il processo di emissione originale di un oggetto da collezione è riconoscibile come irripetibile, il suo valore è solitamente indipendente da qualsiasi azione specifica (o mancanza di azione) da parte dell'emittente iniziale. Un altro esempio, meno ovvio, potrebbe riguardare il possibile sviluppo futuro di meccanismi decentralizzati che consentano meccanismi autonomi, privi di fiducia e resistenti alla censura per far valere diritti / benefici connessi ai beni, al fine di estendere alcune delle caratteristiche della merce bitcoin a più generici / tipi complessi di proprietà digitale. Mentre la proposizione "digital collectible" è assolutamente realistica ma discutibilmente meno interessante, la proposizione "self-enforced-right" è più interessante ma non ancora realistica: applicazioni di questo tipo sono ancora lontane da qualsiasi implementazione effettiva, anche se ci sono molti teorici nicchie ("proprietà intelligente", "DAO", ecc.) che sembrano dare un certo potenziale.

Alternative esistenti

Se il modello dominante di Ethereum-ERC20 per le attività basate su blockchain solleva diverse serie preoccupazioni, le alternative esistenti non riescono ancora a risolverne molte. Le blockchain indipendenti specifiche degli asset non sono sostenibili, mentre le side chains abilitate agli asset sono ancora solo un campo promettente di ricerca (basandosi su ipotesi sociali e legali molto forti come per bootstrap e adozione). La maggior parte dei "meta-protocolli" sviluppati su Bitcoin (protocolli di risorse digitali che si basano su regole di convalida indipendenti, sfruttando la blockchain di Bitcoin come "prova di pubblicazione", al fine di prevenire emissioni e riserve di doppia spesa e audit), fornendo al contempo un soluzione potenzialmente interessante, manca completamente il punto standard / interoperabilità, pur mostrando importanti carenze di scalabilità.

L'idea della "moneta colorata" (un particolare sottoinsieme del "meta-protocollo" Bitcoin, dove la maggior parte delle funzionalità della piattaforma sottostante, come indirizzi, script e importi, sono sfruttati per massimizzare l'interoperabilità) è stata considerata promettente da molti, ma le implementazioni esistenti mostrano ancora limiti importanti. In particolare, ereditano e aggravano ulteriormente le carenze di riservatezza / fungibilità, nonché le carenze di scalabilità, del livello di Bitcoin "on-chain".

Per quanto riguarda la riservatezza / fungibilità, gli schemi di "monete colorate" esistenti fanno molto affidamento sulla presente seria mancanza di queste caratteristiche sul Bitcoin stesso: quantità specifiche di bitcoin (spesso già non abbastanza fungibili nell'attuale impostazione) sono rese ancora meno fungibili, "colorandole" in modi che facilitano notevolmente l'analisi forense, le tecniche di clustering e "contaminazione", spesso invalidando le pratiche esterne di confidenza / miglioramento della fungibilità (cioè coinjoin o altre tecniche in cui la "colorazione basata sull'ordine" e la "colorazione basata sul valore" si interrompono) e relegandole a (pseudo) set di anonimato che passeranno necessariamente da piccoli a irrilevanti, per tutti tranne i principali tipi di asset.

Per quanto riguarda la scalabilità, ereditano i tipici limiti della transazione Bitcoin "on-chain", aggravandoli a causa del rischio di incentivi perversi per il bloating della blockchain, a causa del "dust problem" e per la mancanza di un banale supporto per i light-node sotto forma di soluzioni stile "SPV" (la cui efficacia è comunque seriamente messa in discussione per Bitcoin stesso). Inoltre, molte delle implementazioni esistenti richiedono un numero enorme di deviazioni "ad hoc" dall'infrastruttura Bitcoin standard, rendendo la loro adozione difficile e piena di attriti e riducendo la potenziale standardizzazione / interoperabilità / leva dei punti di forza del modello.

È anche possibile che molte di queste prime implementazioni abbiano sbagliato i tempi (il mercato non mostrava l'attuale forte domanda per uno standard di gestione patrimoniale digitale, quando sono stati concepiti e implementati) e che una nuova proposta rivista potrebbe ora raccolgono più interesse e slancio.

Design generale

Obiettivi generali

Una nuova, migliore proposta per uno standard di gestione di asset basato sulla blockchain dovrebbe soddisfare il più possibile tutti i requisiti razionali del mercato (standardità, auditabilità, mancanza di discernimento, persino indipendenza), oltre a superare molte delle carenze delle alternative esistenti.

Il protocollo "RGB" è principalmente rivolto alle strategie di "scalabilità / stratificazione" di livello 2, ma basa il suo bootstrap su un core "layer 1", che prende in prestito estensivamente i concetti di "moneta colorata" esistenti, massimizzando le proprietà di standardizzazione, facendo leva per quanto possibile l'attuale infrastruttura Bitcoin e interoperando perfettamente con esso con componenti aggiuntivi modulari e minori. Questa parte introdurrà alcune nuove modifiche rispetto alle tradizionali implementazioni di "monete colorate", finalizzate a raggiungere livelli "on-chain" di riservatezza / fungibilità e scalabilità che potrebbero essere considerati almeno vicini a quelli di Bitcoin stesso: l'adozione del Modello di "Client Side Validation", un insieme di best practice responsabili per limitare e disincentivare il bloating blockchain (pay-to-contract anziché op_return), un ampio (pseudo-) anonimato impostato per gli utenti di asset, una completa indipendenza dall'ordine di output. Altre modifiche del "layer 1" sono state introdotte come un mezzo per rendere questo protocollo pienamente compatibile con gli standard principali "layer 2" / "off-chain", con un focus particolare su Lightning Network, in modo da ereditare senza problemi tutto il loro patrimonio di scalabilità e caratteristiche di riservatezza / fungibilità. Inoltre, la proposta di protocollo conterrà una soluzione "layer 2" specifica, specifica e nativa basata sull'idea "Proofmashal".

Caratteristiche principali

Motore del contratto

Per poter comporre e verificare le transazioni di attività relative a un contratto specifico, i wallet abilitati per RGB devono includere un modulo software in grado di analizzare i contratti e le transazioni al fine di verificare in modo deterministico la conformità con i vincoli specificati dal tipo di contratto utilizzato .

I diversi "modelli" di contratto sono definiti in questa specifica, consentendo a RGB di supportare in modo altamente modulare più tipi di contratti con comportamenti predefiniti diversi.

Insieme ad alcuni progetti molto specifici, "popolari", di contratto (che dovrebbero coprire la maggior parte dei casi d'uso), c'è un altro progetto generale che incorpora un esecutore meta-script, che consente la creazione di un contratto molto complesso.

URI esteso

Poiché qualsiasi ipotesi di protocolli aggiuntivi per le comunicazioni fuori banda indebolisce la standardità della proposta, al fine di implementare il protocollo all'interno di un paradigma di convalida lato client sfruttiamo l'unico tipo di comunicazione off-band già ipotizzato come esistente nella maggior parte dei Bitcoin on-chain transazioni da implementare: l'indirizzo “passante”. Quando un beneficiario genera un indirizzo da consegnare al pagatore, trasmette anche le coordinate del server editore selezionato (o collezione di server editore) e alla fine genera un numero, denominato "dark-tag", trasmettendolo al pagatore insieme con l'indirizzo e le informazioni di pubblicazione. Questa funzione può essere sviluppata estendendo il protocollo di fatturazione BOLT.

Server di pubblicazione

Lo schema richiede terze parti aggiuntive concordate (a livello di transazione) che memorizzano la catena di prove crittografate e accettano le domande correlate, possibilmente in un "filtro Bloom" per aumentare la privacy (i falsi positivi possono essere aggiunti casualmente per mantenere anche più privacy). Nel contesto di una risorsa emessa, questi server "editore" potrebbero essere gestiti dall'emittente stesso. Più in generale, possono essere gestiti singolarmente dai ricevitori o da una o più terze parti indipendenti selezionate dal mittente attingendo da un insieme definito dai destinatari. L'archiviazione e la trasmissione delle dimostrazioni potrebbero essere in teoria ottenute tramite sistemi decentralizzati (BitTorrent, IPFS, Siacoin, ecc.), ma i guadagni di resistenza alla censura non compensano la maggiore complessità. Inoltre, l'integrazione Proofmarshal (vedi sotto) richiede comunque una terza parte centralizzata, che potrebbe essere efficacemente sfruttata per l'integrazione della rete Lightning (vedi sotto).

Integrazione di rete Lightning

Essendo il protocollo basato su UTXO, sarà possibile collegare una o più risorse a un canale Lightning Network, che diventa colorato, scambiando gli aggiornamenti di stato che sono conformi allo schema di asset, con forti garanzie che la distribuzione degli asset sarà preservata anche nel caso di chiusure non consensuali. In questo modo, sarà possibile sfruttare le funzionalità di scalabilità e privacy della rete Lightning, nonché gli scambi atomici abilitati a LN e la scoperta di percorsi basati su LN per lo scambio di risorse decentralizzato.

Integrazione con Proofmarshal

Il protocollo includerà anche un'altra strategia L2 per scalabilità / fungibilità, un'implementazione specifica del concetto "Proofmarshal", basata su "Sigilli monouso" e "Proof-of-Publication-Ledger”.

In questa integrazione, un server editore può anche fungere da "sigillante", con la capacità di censurare le transazioni ma non di manipolarle / alterare / falsificarle, committando più prove da diversi utenti anonimi a un singolo UTXO. Ciò potrebbe disaccoppiare la funzione anti-doppia spesa della blockchain Bitcoin dalle transazioni di asset specifici, rendendo possibile "sigillare" un numero enorme di persone che spendono un singolo UTXO Bitcoin.

Fonte:

https://github.com/rgb-org/spec/blob/master/00-introduction.md