RGB smart contracts

Colored coins in een wallet

Citadel wallet setup

RGB is een manier om Smart Contracts te gebruiken op Lightning (een 2e laag op bitcoin). Het doel is om private en schaalbare smart contracts op Bitcoin te maken.

Het originele idee is voorgesteld door Giacomo Zucco en Peter Todd in 2016, en bedrijven als Tether Inc en Bitfinex zijn sponsors van het project. De beheerder van het project is de LNP/BP Standards Association in Zwitserland.

De naam RGB is een knipoog naar Colored Coins; Rood, Groen en Blauw zijn de primaire kleuren waar je alle kleuren mee kan mengen. RBG is expliciet geen nieuwe blockchain.

Wat je met RGB kan doen:

• Digitale activa uitgeven, zoals aandelen of andere effecten, waardepapieren
• Verzamelobjecten uitgeven, zoals digitale voetbalplaatjes of pokémonkaarten (NFT's)
• Maken en beheren van digitale identiteiten
• Decentrale exchanges opzetten (DEX'en over Lightning)
• Scam-tokens en shitcoins uitgeven op bitcoin
• ... Maken en draaien van wat voor ander soort smart contract dan ook ...

RGB-contracten kunnen worden gezien als bearer bonds (effect aan toonder) waar regels aan kunnen worden gesteld.

Stappen voor uitgeven en gebruiken van RGB-contracten

Directed acyclic graph

Grofweg volgt een RGB-contract de volgende levensweg:

1. Elk RGB-contract begint in zijn startpositie: de genesis state, ingesteld door de uitgever van het RGB-contract. Bij het uitgeven van het contract bepaalt de uitgever de regels: het schema. Naast de genesis state houdt het RGB-contract zijn status bij in een "directed acyclic graph" (DAG, graaf, zie rechts voor voorbeeld). Zie dit als een logboek van eigendomveranderingen (state transitions). De genesis state en de state transactions graaf worden beiden off-chain opgeslagen, dit is dus client validated data. Elk RGB-contract heeft zijn eigen state historie en data.
2. De state wordt gekoppeld aan bitcointransacties (UTXOs). Dit maakt de UTXO een Single Use Seal. Degene die de UTXO mag uitgeven is de eigenaar, ze hebben de owning state. De eigenaar mag het smart contract veranderen door een state transition uit te voeren.
3. Bij een state transition wordt de oude UTXO uitgegeven: het seal wordt gesloten. Er wordt direct een nieuwe UTXO gemaakt. De dergelijke state transaction gebeurt altijd met een set van 2 transacties. De informatie over de state transition wordt off-chain opgeslagen in de DAG, deze nieuwe data noemen we de witness.
4. De state transition verandert de status van het smart contract. Dit gebeurt in RGB door het oude seal te sluiten, en de state te koppelen aan nieuwe Single Use Seals. Het is afhankelijk van het contracttype wat een state transition "betekent". De state transitions moeten zich aan de regels van het contract (schema) houden, kunnen metadata bevatten, en kunnen gebruik maken van Simplicity scripts om het contract "slimmer" te maken).
5. Door de state transition is de state nu veranderd: er is een slimme transactie gedaan!

Door Lightning toe te voegen aan de bovenstaande stappen, wordt het mogelijk om state-veranderingen te doen met meerdere partijen tegelijk (multiparty coordinated state changes).

Concepten

Lagen, anonimiteit en schaalbaarheid

RGB werkt rond laag 2/3 in het Bitcoin en Lightning-netwerk. De contracten worden door nodes (clients) geverifiëerd. Het schaalt onafhankelijk van de blockchain. Er worden technieken als mimblewimble en liquid gebruikt om zero-knowledge proofs en privacy te bereiken. (mimblewimble maakt het mogelijk om data compacter op te slaan in een blok. En daarnaast voegt het privacy toe omdat de individuele transacties als één transactie worden gerepresenteerd)

RGB zet geen contractdata in de blockchain, zodat het schaalbaarder is dan ETH/EOS/DOT en dergelijken. Ook zijn blockchains inzichtelijk voor iedereen, wat het minder anoniem maakt, en dus minder geschikt voor private smart contracts. De blockchain wordt als "commitmentlaag" gebruikt.

Verschillen met andere systemen

• Er wordt geen data op de blockchain gezet, wat zorgt dat de eigenaar van het RGB-contract de data zelf verantwoordelijk is voor het bewaren van data.

• Contracten worden offchain doorgegeven, via bijvoorbeeld een website of bittorrent. Dit is het Proof Passage-proces. Bij het doorgeven van een RGB-contract wordt zowel het contract als de bewijzen offchain doorgegeven (zie Seals hieronder)

• De validatie van contracten gebeurt door de clients. Je vertrouwt miners niet om je contract uit te voeren, je hebt ze slechts nodig als "proof of publication". Validatie doe je zelf.
• Uitgevers van het contract weten niet wie de eigenaar van het contract is (anonimiteit).

Vertrouwen

• De uitgever van RGB-contracten kan geen extra tokens creëren, dus schaarste is gegarandeerd.
• De uitgever kan jouw tokens niet uitgeven. De regels van het RGB-contract staan vast en zijn tijdens uitgave vastgelegd in het schema.
• Je moet de uitgever wel vertrouwen dat het token doet dat ze zeggen dat ze doen, als er een component in de fysieke wereld is.
  • Als een uitgever belooft dat je eigenaar wordt van een echt bedrijf, op basis van uitgegeven RGB-tokens, dan moet dat in de echte wereld eerlijk gelinkt worden (Klassiek Orakel-probleem).

Eigendom en validatie

• Eigendom definiëert wie de state kan aanpassen.
  • Het eigendom wordt bepaald door Bitcoin Script, op blockchainniveau.
• Validatieregels bepalen hoe de state aangepast mag worden.
  • Validatie gebeurt door client side validation.
  • Validatieregels kunnen turing-complete Simplicity scripts gebruiken

Het hoe en het wie wordt in RGB los van elkaar gezien. Dit is beter voor de schaalbaarheid: verschillende lagen kunnen niet worden gemixed. Het is met RGB niet mogelijk om turing-complete scripts op de blockchain uit te voeren, die leiden tot schaalbaarheidsproblemen (zie ETH/EOS/DOT).

Single Use Seals

Een basisprobleem dat Bitcoin oplost is het double-spend probleem: één transactie kan eenmalig uitgegeven worden. Bij smart contracts wil je, zodra het is uitgevoerd en het script een uitkomst heeft, dit niet ongedaan kan worden gemaakt, of dat de andere uitkomst alsnog kan gebeuren. RGB gebruikt hiervoor "Single Use Seals". Seals zijn zegels die aan een UTXO gekoppeld zijn en maar één keer kunnen worden gesloten (uitgegeven): Zodra de bitcointransactie (UTXO) wordt uitgegeven, is de seal gesloten. Dit kan uiteraard maar één keer gebeuren.

Tokens worden gelinkt aan een open seal. Zodra een seal wordt gesloten, worden de coins verbonden aan een nieuw open seal. De keten van eigenaarschap, met de links van seal naar UTXO, worden offchain door de eigenaar van de RGB-token overgedragen naar een nieuwe eigenaar. De data, inclusief metadata van het token, worden buiten de blockchain om doorgegeven aan de nieuwe eigenaar. Er wordt een nieuwe UTXO gemaakt om eigenaarschap over te dragen.

UTXOs

Er worden UTXO's (transacties) gebruikt om eigenaarschap over te dragen. De transacties zijn klein en gebruiken OP_RETURN-operators.

Contracttypen

Er zijn drie typen contracten:

1. Collectibles (schaarse goederen)
2. ICO ("iedereen die voor blok X, Y bitcoin betaalt naar contract Z, kan die betaling gebruiken als bewijs van eigenaarschap"). Het is dus niet nodig om geld te ontvangen als centrale partij, om je waardepapieren op RGB te zetten: de betaling is bewijs van eigenaarschap.
3. Alternatieve munten ("iedereen die voor blok X, Y bitcoin betaalt naar contract Z, is eigenaar van coin BLA")

Het contracttype wordt door de uitgever bepaald, en vastgelegd in het schema.

State transactions

State transactions veranderen de status van het smart contract, door een oude seal te sluiten, en het RGB-contract te verbinden aan nieuwe Seals. De state transactions moeten zich houden aan de regels zoals in het schema gedefiniëerd.

Schema

Het schema van een contract bepaalt het gedrag van een RGB-contract. Het schema wordt bepaald door de uitgever van het contract en bevat:

• Toegestane soorten state van het contract
• Toegestane soorten seals die gebruikt mogen worden
• Toegestane soorten metadata dat toegevoegd mag worden aan het contract
• Toegestane soorten scripts door het contract
  • In het script kunnen Turing-complete Simplicity scripts worden gebruikt, om logica te definiëren die de toegestane state changes beheert.

Het schema kan dus worden gezien als de validatieregels voor het contract. De validatie gebeurt client side.