RGB versterkt de schaalbaarheid en privacymogelijkheden van Bitcoin en Lightning Network

TL; DR

• RGB werkt als een Layer 2/3-oplossing op het Bitcoin en Lightning Network.client-side validatieparadigma, waarin alle slimme contractgegevens buiten Bitcoin-transacties worden ondergebracht. Dit ontwerp garandeert de werking van het systeem bovenop het Lightning Network, waardoor er geen noodzaak is voor aanpassingen aan de LN-protocollen.
  
• RGB slimme contracten zijn ontworpen voor schaalbaarheid en vertrouwelijkheid. Het systeem ondersteunt privé- en wederzijds eigendom, abstraheert en scheidt belangen en vertegenwoordigt een post-blockchain, Turing-complete vorm van betrouwbaar gedistribueerd computergebruik zonder de noodzaak om nieuwe tokens te introduceren.
  
• RGB-contracten zijn georganiseerd in afzonderlijke segmenten die ‘shards’ worden genoemd, elk met zijn eigen geschiedenis en gegevens, waardoor de schaalbaarheid wordt vergroot en de vermenging van geschiedenissen uit verschillende contracten wordt voorkomen. Ze communiceren via het Bifrost-protocol op het Lightning Network, waardoor gecoördineerde veranderingen tussen meerdere partijen mogelijk zijn, vergelijkbaar met DEX's die op het Lightning Network opereren.
  
• RGB maakt gebruik van zegels voor eenmalig gebruik defiom veiligheidsredenen via Bitcoin UTXO's. Elke partij die over de geschiedenis van een slimme contractstaat beschikt, kan de uniciteit ervan verifiëren, door gebruik te maken van het script van Bitcoin define eigendoms- en toegangsrechten.
  
• In RGB zijn staatseigendom en validatie afzonderlijke entiteiten. Het eigendom wordt beheerd door het Bitcoin-script, een niet-Turing Complete-systeem. Validatieregels worden daarentegen gedicteerd door het RGB-schema met behulp van het Turing Complete Simplicity/Contractum/Rust-script.
  
• Elk RGB-smartcontract wordt geassocieerd met een unieke staat met behulp van zegels voor eenmalig gebruik. De zegels en de staat volgen specifieke regels en validaties die zijn vastgelegd door de maker van het contract en worden beheerst door een ‘schema’. Dit schema fungeert als een regelset voor het controleren van contractgegevens aan de clientzijde, waardoor een hoog niveau van protocolschaalbaarheid en privacy mogelijk wordt gemaakt.
  
• Het ontwerp van RGB is zeer interoperabel met bestaande Bitcoin- en Lightning Network-technologieën, waardoor een naadloze integratie met deze platforms en eventuele toekomstige upgrades mogelijk wordt gemaakt.
  
• In tegenstelling tot de imperatieve programmeerstijl van veel blockchain-platforms, gebruikt RGB een declaratieve stijl. Deze aanpak richt zich op het schetsen van het gewenste resultaat in plaats van op het beschrijven van de specifieke stappen om dit te bereiken.
  
• RGB maakt gebruik van verschillende geavanceerde technologieën, waaronder AluVM voor deterministische draagbare computertaken, PRISM voor gedeeltelijk gerepliceerde computersystemen met oneindige toestanden, en Storm voor op escrow gebaseerde, betrouwbare opslag met behulp van zk-proofs. Deze technologieën dragen bij aan de robuustheid, vertrouwelijkheid en uitbreidbaarheid van RGB.
  
• RGB (v0.10) introduceert opmerkelijke verbeteringen in de gebruikerservaring en integratieprocessen, waardoor de activiteiten worden gestroomlijnd en de afhankelijkheden worden geminimaliseerd. De bijgewerkte versie beschikt over een meer uniforme bibliotheek-API en opdrachtregeltool, waardoor deze toegankelijker en gebruiksvriendelijker wordt.

Korte beschrijving

RGB is een protocol dat is ontworpen voor het uitgeven van tokens op het Bitcoin-netwerk met verbeterde privacy en compatibiliteit met het Lightning Network. Het bouwt voort op het concept van ‘gekleurde munten’, zoals die worden gebruikt in het OmniLayer-protocol, waarbij metagegevens in Bitcoin-transacties een tokenoverdracht aangeven. USDT-transacties op OmniLayer functioneren bijvoorbeeld als Bitcoin-transacties, aangevuld met aanvullende gegevens over de USDT-tokenbewegingen. Deze methoden worden echter geconfronteerd met beperkingen, zoals beperkingen van de gegevensgrootte in OP_RETURN-uitvoer, intensieve blockchain-scanning en beperkte privacy als gevolg van zichtbaarheid in de keten.

RGB pakt deze problemen aan door het merendeel van de validatieprocessen weg te verplaatsen van de Bitcoin-blockchain. Het maakt gebruik van validatie aan de clientzijde en maakt gebruik van zegels voor eenmalig gebruik om tokens te verbinden met de UTXO’s van Bitcoin, terwijl de privacy van de gebruiker behouden blijft.

Tokens worden overgedragen door een bericht met RGB-betalingsinformatie binnen een Bitcoin-transactie te versturen, waardoor de tokens van de ene UTXO naar de andere kunnen gaan zonder een spoor achter te laten op de Bitcoin-transactiegrafiek. Dit verbetert de privacy aanzienlijk, omdat RGB-transacties tokens discreet “teleporteren”, waarbij RGB-specifieke gegevens via particuliere off-chain kanalen worden doorgegeven.

Om eigendom te garanderen en inflatie te voorkomen, moeten ontvangers bovendien de volledige transactiegeschiedenis van de ontvangen tokens valideren. RGB maakt toekomstige upgrades mogelijk zonder de noodzaak van harde vorken, waardoor mijnwerkers de activastroom niet kunnen traceren, waardoor een grotere weerstand tegen censuur wordt geboden. In tegenstelling tot traditionele blockchain-structuren werkt RGB zonder de noodzaak van blokken of ketens, waardoor het wordt gepositioneerd als een niet-blok gedecentraliseerd protocol dat hoge vertrouwelijkheid, veiligheid en schaalbaarheid belooft.

Inleiding en visie

Oneliner: Een door de klant gevalideerd staats- en slim contractsysteem dat werkt op Layer 2/3 in Bitcoin en Lightning Network.

Meer informatie:

RGB is een schaalbaar en vertrouwelijk slim contractsysteem voor Bitcoin & Lightning Network. RGB slimme contracten werken met validatie aan de clientzijde paradigma, huisvesting alle slimme contractgegevens buiten Bitcoin-transacties, d.w.z. Bitcoin-blockchain of Lightning-kanaalstatus. Hierdoor kan het systeem bovenop Lightning Network werken zonder enige wijziging aan de LN-protocollen en wordt tevens een basis gelegd voor een hoog niveau van protocolschaalbaarheid en privacy.

Slimme contracten belichamen principes van privé- en wederzijds eigendom, abstractie en de scheiding van belangen. Ze vertegenwoordigen een ‘post-blockchain’, Turing-complete vorm van betrouwbaar gedistribueerd computergebruik waarvoor geen introductie van tokens nodig is.

RGB-contracten opereren in afzonderlijke segmenten die ‘shards’ worden genoemd. Elke scherf heeft zijn eigen geschiedenis en gegevens, wat betekent dat verschillende contracten hun geschiedenis niet vermengen. Deze methode verbetert de schaalbaarheid. De term ‘shard’ wordt gebruikt om aan te tonen dat RGB vergelijkbare doelen bereikt als wat was bedoeld met het shards-concept van Ethereum.

Hoewel ze onafhankelijk functioneren, kunnen RGB-contracten communiceren via het Bifrost-protocol op het Lightning Network. Dit maakt gecoördineerde veranderingen tussen meerdere partijen mogelijk. Het zorgt er bijvoorbeeld voor dat DEXen via het Lightning Network kunnen functioneren.

Technologie & Architectuur

Overzicht op hoog niveau van RGB-werking en afdichtingen voor eenmalig gebruik

Figuur 1. Overzicht op hoog niveau van de werking van RGB.
Bron: LNP/BP Vereniging Github.

Als beveiligingsmechanisme gebruikt RGB afdichtingen voor eenmalig gebruik defivia bitcoin UTXO's, die elke partij met een slimme contractstatusgeschiedenis de mogelijkheid bieden om de uniciteit ervan te verifiëren. In wezen maakt RGB gebruik van het Bitcoin-script voor zijn beveiligingsmodel en defines ownership en toegangsrechten.

Figuur 2. RGB-werkprincipe op hoog niveau.
Bron: “Driving Mass Adoption of Crypto: How the RGB Protocol is Illuminating the Future of Bitcoin” door Waterdrip Capital.

Elk RGB slim contract is dat wel defined door een genesis staat, gemaakt door de slimme contractuitgever (of, simpel gezegd, emittent) en een gerichte acyclische grafiek (DAG) van toestandsovergangen bewaard als door de klant gevalideerde gegevens.

Figuur 3. Transacties, gesloten zegel en getuige.
Bron: LNP/BP Vereniging Github.

We kunnen het als volgt samenvatten: elke transactie heeft een UTXO, en het bezit van deze UTXO geeft de eigenaar het recht om de staat te bezitten. Eigendom bepaalt wie de blockchain-status kan wijzigen en de UTXO kan ‘uitgeven’. De persoon die de staat in handen heeft, wordt de partij genoemd staat bezitten.

De partij heeft de bevoegdheid om het relevante gedeelte van de slimme contractstatus te wijzigen door een nieuwe statusovergang te genereren en deze in een transactie te bevestigen, waarbij gebruik wordt gemaakt van de output die de vorige status bevat.

Het proces betekent sluiting van een zegel over de staatstransitie, en een paar dat de bestedingstransactie en bijbehorende extra-transactiegegevens over de statusovergang omvat, wordt a genoemd Getuige (afgebeeld in een afbeelding hierboven).

Eigendom en toegang: kerneigenschappen

Figuur 4. Eigendom en toegang.
Bron: LNP/BP Vereniging Github.

Staatseigendom en validatie zijn verschillende concepten. Validatieregels specificeren hoe de staat kan veranderen, maar geven niet aan wie de verandering mag bewerkstelligen. 

Aan de andere kant wordt het eigendom gecontroleerd door het Bitcoin-script op het Bitcoin-blockchainniveau, wat niet Turing Complete is. Validatieregels daarentegen worden beheerst door het RGB-schema dat gebruik maakt van Simplicity/Contractum Script, dat wil zeggen dat ze Turing Complete zijn. 

RGB-schema

Bij slimme RGB-contracten krijgt elk contract een unieke status toegewezen via zegels voor eenmalig gebruik. Deze zegels hebben, samen met de staat, specifieke regels en validaties, die in het begin zijn vastgelegd door de maker van het contract. Deze opzet wordt bepaald door een ‘schema’, dat functioneert als een reeks regels om contractgegevens aan de klantzijde te valideren. Het schema kan complexe scripts bevatten die een integraal onderdeel vormen van de logica van het contract.

Figuur 5. RGB-schema.
Bron: LNP/BP Vereniging Github.

Validatie en ontwerpprincipes aan de klantzijde

Figuur 6. RGB-validatie aan de clientzijde.
Bron: LNP/BP Vereniging Github.

1. Sterk eigendom: In RGB hebben slimme contracten een duidelijk defieigenaar of eigenaren. Alleen aangewezen eigenaren hebben de bevoegdheid om de staat van het contract te wijzigen. Deze contracten schetsen afzonderlijke rechten of activiteiten, gecategoriseerd als openbaar (toegankelijk voor iedereen) of in eigendom (beperkt tot de eigenaar).
2. Vertrouwelijkheid: Informatie binnen het contract wordt vertrouwelijk behandeld en is alleen bekend bij de deelnemers, vooral de eigenaren van de staat. Deelnemers hebben de mogelijkheid om bepaalde gegevens openbaar te maken, maar standaard is alle informatie privé. Deze vertrouwelijkheid verhindert dat externe analysetools toegang krijgen tot de gegevens, waardoor wordt gegarandeerd dat er geen gevoelige informatie in openbare grootboeken wordt opgeslagen.
3. Scheiding van zorgen: RGB heeft een modulair ontwerp met verschillende lagen, die elk een specifieke taak toegewezen krijgen. Deze lagen werken onafhankelijk, waardoor de noodzaak voor lagere lagen om zich bewust te zijn van de structuur van de hogere lagen wordt geëlimineerd. Dit ontwerp verbetert de organisatie en efficiëntie van het systeem.
4. uitbreidbaarheid: Het systeem is eenvoudig uit te breiden, waardoor geavanceerde slimme contracten kunnen worden gemaakt en geïntegreerd zonder dat het kernprotocol hoeft te worden gewijzigd of de volledige RGB-bibliotheek opnieuw moet worden samengesteld.
5. Determinisme: De validatielogica van RGB is deterministisch en levert consequent identieke resultaten op met dezelfde invoer en de heersende staat van het onderliggende blockchain- of Lightning Network-kanaal. Deze consistentie wordt bereikt door twee hoofdcomponenten: De kernvalidatielogica, geschreven in Rust, is hetzelfde op alle systemen met RGB. B. Contractspecifieke validatielogica draait op AluVM, een virtuele machine die een consistente reeks instructies biedt, ongeacht het platform.
6. LNP/BP-interoperabiliteit: RGB is ontworpen om naadloos samen te werken met bestaande Bitcoin- en Lightning Network-technologieën. Het is ook gebouwd om compatibel te zijn met toekomstige upgrades van deze technologieën.
   

Benadering van RGB en Pure Blockchain/L1-aanpak

De pure blockchain/L1-aanpak is verkeerd, stelt het RGB-team.

Figuur 7. RGB-opmerkingen over de Blockchain/L1-aanpak.
Bron: LNP/BP Vereniging Github.

RGB’s aanpak: declaratief versus imperatief programmeren:

• De meeste blockchain-platforms, waaronder Ethereum, maken gebruik van slimme contracten die in een imperatieve stijl zijn geschreven. In deze benadering functioneert het contract als een programma dat expliciet de stapsgewijze uitvoering van taken aanstuurt, wat lijkt op een nauwkeurig en gedetailleerd recept.
• Deze imperatieve programma’s zijn vaak behoorlijk restrictief en worden beperkt door de mogelijkheden van het onderliggende blockchain-platform. Ook al worden ze soms Turing-compleet genoemd, ze brengen aanzienlijke beperkingen met zich mee.

Declaratieve aard van RGB Smart Contracts:

• RGB maakt daarentegen geen gebruik van imperatieve programmering. In plaats daarvan maakt het gebruik van een speciale vorm van functionele programmering waarbij slimme contracten worden gebruikt defideclaratief ned.
• Bij declaratief programmeren beschrijf je, in plaats van te beschrijven hoe je iets moet doen, wat de uitkomst zou moeten zijn. Het is alsof je schetst hoe een maaltijd eruit moet zien, in plaats van stapsgewijze kookinstructies te geven.
• Het “Schema” in RGB is een declaratief defivan een slim contract. Het specificeert de regels en voorwaarden van het contract, maar niet de exacte volgorde van de handelingen om deze te bereiken.

Paradigmaverschuiving in programmeren:

• De overgang van de imperatieve stijl van Ethereum naar de declaratieve stijl van RGB bij het programmeren van slimme contracten is vergelijkbaar met de verschuiving van traditioneel imperatief programmeren naar functioneel of declaratief programmeren bij algemene softwareontwikkeling.
• Deze verschuiving vereist een andere mentaliteit: focussen op het ‘wat’ (de gewenste resultaten) in plaats van op het ‘hoe’ (de specifieke stappen om die resultaten te bereiken).

Eenvoud

Het oorspronkelijke plan omvatte de integratie van Simplicity in RGB, en de inspanningen waren gericht op het garanderen van compatibiliteit vanaf dag 1. Gezien de trage voortgang van de ontwikkeling van Simplicity en de onzekerheid rond de releasetijdlijn, werd het echter duidelijk dat het onpraktisch was om erop te vertrouwen. De lopende RGB-release, die momenteel in voorbereiding is, riep vragen op over de opname van Simplicity.

Omdat we beseften dat er geen betrouwbaar tijdschema voor Eenvoud bestond, zijn we begonnen met het onderzoeken van alternatieven (WASM, EVM (als grap), IELE enz.). Uiteindelijk werd het duidelijk dat het ontwikkelen van een eigen virtuele machine voor RGB de enige haalbare optie was, ter vervanging van de aanvankelijke afhankelijkheid van Simplicity.

Daarom hebben we besloten om te creëren AluVM – puur functionele, zeer draagbare, op Rust gebaseerde virtuele machine voor client-side gevalideerde slimme contracten (RGB), Lightning Network, deterministisch gedistribueerd en edge computing.

Prisma

PRISM staat voor ‘gedeeltelijk gerepliceerde oneindige toestandsmachines’.

RGB-technologie defiEr zijn regels voor het ontwikkelen van slimme contracten op een basisniveau, genaamd Schema, maar het beperkt niet alle toekomstige acties van het contract met één enkel, overkoepelend algoritme. In plaats daarvan voert elk knooppunt op het netwerk individuele bewerkingen uit, en zowel de status van het contract als het contract zelf blijven geldig zolang deze bewerkingen voldoen aan de regels van het Schema. 

Bovendien beperkt deze aanpak de historische evolutie van het contract niet met een vooraf bepaald algoritme. Een contract kan dus gevarieerd gedrag vertonen, zolang elke wijziging aan specifieke validatieregels voldoet. Deze methode richt zich op lokale regels in plaats van op een globaal algoritme.

Ethereum gebruikt daarentegen een mondiaal algoritme waarbij elke bewerking de gehele status van het slimme contract beïnvloedt. Met RGB werk je met slechts een deel van de staat van het contract, waarbij je de regels lokaal toepast. Dit biedt een breder scala aan mogelijkheden voor contractevolutie.

Hieronder ziet u een overzicht op hoog niveau van de verschillen tussen staatskanalen en client-side-validatie: 

Figuur 8. Gedistribueerde systeemscheiding.
Bron: LNP/BP Vereniging Github.

Meer specifieke verschillen zijn als volgt: 

Figuur 9. Vergelijking van staatskanalen en validatie aan de clientzijde.
Bron: LNP/BP Vereniging Github.

AluVM

AluVM – (algoritmische logische eenheid VM) is een puur functionele RISC virtuele machine ontworpen voor deterministische draagbare computertaken

AluVM onderscheidt zich door gebruik te maken van een registergebaseerd systeem dat willekeurige geheugentoegang verbiedt. Dit ontwerp verbetert de geschiktheid van AluVM voor toepassingen zoals slimme contracten, uitvoering van externe code en gedistribueerde en edge computing. De kernsterkten van AluVM liggen in het determinisme, de robuustheid en het vermogen voor formele code-analyse.

Sleuteleigenschappen: Uitzonderlijk, draagbaarheid, sandboxing, beveiliging, uitbreidbaarheid.

De Instruction Set Architecture (ISA) van AluVM is ontworpen om aanpasbaar te zijn, waardoor het verschillende runtime-omgevingen voor verschillende toepassingen kan creëren. AluVM zelf is een zeer voorspelbare, functionele, op registers gebaseerde virtuele machine en ISA. 

Hoewel de willekeurige geheugentoegang wordt beperkt, blinkt de AluVM ISA uit in het uitvoeren van rekenkundige taken, inclusief taken die verband houden met elliptische curven. Uniek is dat de omgeving van de VM de AluVM ISA kan uitbreiden, waardoor functionaliteiten kunnen worden toegevoegd zoals het laden van gegevens in de registers van de VM en het ondersteunen van gespecialiseerde instructies (bijvoorbeeld SIMD) die zijn toegesneden op specifieke toepassingen.

AluVM is vooral bedoeld voor gebruik in gedistribueerde systemen waar consistentie en betrouwbaarheid op verschillende platforms belangrijker zijn dan verwerkingssnelheid. De primaire toepassingen voor AluVM, met de juiste ISA-extensies, omvatten blockchain-technologie, berekeningen die cruciaal zijn voor consensus in netwerken, edge computing, multiparty computing (waaronder deterministisch machinaal leren), client-side-validatie, beperkt Internet2-computing en genetische algoritmen. Deze applicaties profiteren van het vermogen van AluVM om consistent en veilig te presteren in verschillende omgevingen.

Figuur 10. AluVM-vergelijking.
Bron: LNP/BP Vereniging Github.

Contractum

Contractum onderscheidt zich van andere slimme contract-programmeertalen door de functionele mogelijkheden van Haskell te combineren met de nabijheid van het bare metal uit Rust. Het bezet een niche die voorheen ontoegankelijk was voor slimme contracten:

Figuur 11. Vergelijking van Contractum, Eenvoud en andere talen.
Bron: contractum.org

Contractum is een programmeertaal die wordt gebruikt om RGB-contracten te maken. Contracten afgesloten met Contractum worden gecontroleerd met behulp van een methode genaamd client-side-validatie. Deze aanpak voegt geen gegevens toe aan de Bitcoin-blockchain, die kan worden vergeleken met een vorm van sharding-technologie, verder verbeterd met behulp van zero-knowledge proofs. 

Validatie aan de clientzijde scheidt ook de ontwikkeling van het contract van blockchain-transacties, waardoor het onmogelijk wordt om deze transacties te volgen of te analyseren via traditionele blockchain-analysemethoden.

Figuur 12. Contractumkenmerken.
Bron: contractum.org

Om deel te nemen aan Contractum-ontwerp is het belangrijk om vertrouwd te raken met de technologieën die worden gebruikt door RGB slimme contracten:

Figuur 13. Technologieën die worden gebruikt door RGB slimme contracten.
Bron: contractum.org

Recente updates in nieuwe versie RGB v0.10

In de nieuwste versie van RGB (versie 0.10) zijn verschillende geavanceerde technische verbeteringen geïmplementeerd, waardoor de mogelijkheden van het raamwerk voor de ontwikkeling van complexe applicaties zijn verbeterd. Deze updates zijn primair gericht op de introductie van een Global State voor elk RGB-contract, de integratie van contractinterfaces en de adoptie van een strikt typesysteem.

Mondiale staat in RGB-contracten

De Global State-functie is een cruciale innovatie in RGB v0.10, waardoor elk contract een universeel toegankelijke status kan behouden. Deze status is niet alleen toegankelijk voor de virtuele RGB-machine, maar ook voor externe clients zoals portemonnees en andere applicaties.

Het nut van deze mondiale staat is van cruciaal belang voor het bouwen van geavanceerde toepassingen op het RGB-platform, vooral die toepassingen die ingewikkeld staatsbeheer vereisen, zoals synthetische activa en algoritmische stablecoins. Het maakt een meer dynamische interactie met de staat van het contract mogelijk, die verder reikt dan de beperkingen van traditionele slimme contractarchitecturen.

Contractinterfaces

RGB v0.10 introduceert ‘contractinterfaces’ als een gestandaardiseerd communicatieprotocol voor diverse slimme contracten. Deze interfaces functioneren op dezelfde manier als de contractuele ABI’s (Application Binary Interfaces) en ERC’s (Ethereum Request for Comments) van Ethereum.

Een belangrijk onderscheid in de aanpak van RGB is de niet-verplichte standaardisatie van deze interfaces en hun inherente verpakking met contracten, waardoor de noodzaak voor afzonderlijke distributie wordt geëlimineerd. Dit vergemakkelijkt semantisch bewuste interacties tussen gebruikers en contracten via gebruikersinterfaces in portemonnees en andere software.

Deze interfaces zijn niet statisch; ontwikkelaars kunnen bestaande contracten in de loop van de tijd uitbreiden met extra interfaces, waardoor de functionaliteit wordt verbeterd zonder de onveranderlijke contractkern te wijzigen.

Strikt typesysteem

Het nieuwe coderingsformaat in RGB v0.10 maakt gebruik van een ‘strikte typen’-systeem. Dit systeem is een nieuwe functionele datatypebenadering, ontworpen voor efficiënte representatie en introspectie van contractstaten binnen het RGB-framework.

Het strikte typesysteem zorgt voor zekerheid tijdens het compileren van de gegevensgrootte, wat vooral gunstig is voor gebruik op apparaten met beperkte bronnen, zoals low-end hardware wallets met beperkte geheugenmogelijkheden.

Bovendien is de gehele RGB-consensuslaag in versie 0.10 gecompileerd in strikte typen, wat een basis vormt voor formele bewijzen van binaire compatibiliteit tussen verschillende softwareversies. Deze functie vereenvoudigt en beveiligt niet alleen het gebruik van RGB, maar stelt uitgevers van activa en contractontwikkelaars ook in staat aanvullende metadata aan hun activa of contracten toe te voegen. Dergelijke metadata kunnen een cruciale rol spelen bij het verifiëren van de identiteit en authenticiteit van activa of contracten in het RGB-ecosysteem.

Op roest gebaseerde slimme contracten

RGB-slimme contracten kunnen nu in Rust worden geschreven, waarbij gebruik wordt gemaakt van de mogelijkheden van de taal voor typeveiligheid en prestaties.

De strikte integratie van systeemtypes vergemakkelijkt de directe compilatie van Rust-gegevenstypen in RGB-contractstructuren, waardoor de efficiëntie en betrouwbaarheid van de contractcode wordt verbeterd.

Verbeterde mogelijkheden voor staatsintrospectie

Slimme contracten in RGB v0.10 kunnen hun eigen status inspecteren binnen de validatiecode die wordt uitgevoerd door de virtuele RGB-machine.

Deze functie is met name handig voor het maken van complexe contracten die interageren met Bitcoin-transacties, discrete logcontracten en andere ingewikkelde datastructuren, waardoor de reikwijdte en functionaliteit van slimme RGB-contracten wordt vergroot.

URL-gebaseerd factuurformaat

De update introduceert een nieuw factuurformaat dat het vorige Bech32m-gecodeerde systeem vervangt.

Deze nieuwe, op URL's gebaseerde facturen zijn aanzienlijk korter en gebruiksvriendelijker, waardoor eenvoudigere verificatie en automatisch openen met vooraf geconfigureerde software mogelijk is.

WASM-ondersteuning (WebAssembly).

De RGB-standaardbibliotheek is nu compatibel met omgevingen zonder I/O- en bestandssysteemtoegang, zoals webpagina's of browserplug-ins.

Dit breidt de potentiële gebruiksmogelijkheden van RGB uit, waardoor het naadloos kan werken in een breed scala aan webgebaseerde applicaties en extensies.

Taproot-descriptoren en aangepaste afleiding

RGB v0.10 maakt gebruik van op taproot gebaseerde OP_RETURN-toezeggingen (ook wel tapret genoemd), waardoor ondersteuning op descriptorniveau nodig is voor portemonnees om transacties met aangepaste uitvoer te herkennen.

De introductie van aangepaste afleidingsindexen in deze versie voorkomt dat niet-RGB-portemonnees onbedoeld outputs uitgeven die RGB-items bevatten, waardoor de integriteit van deze activa wordt gewaarborgd.

Vereenvoudigde afhankelijkheden

De RGB-consensuslaag in versie 0.10 heeft zijn afhankelijkheden verminderd, met name door afstand te nemen van een aangepaste, kogelvrije implementatie die oorspronkelijk was afgeleid van Grin-projecten.

Deze vermindering van de afhankelijkheden verbetert de stabiliteit van de API en de algehele robuustheid van het systeem.

Gestroomlijnd integratieproces

De update vereenvoudigt operationele workflows door de behoefte aan meerdere API-aanroepen en complexe codering van datastructuren in meerdere talen te verminderen.

RGB-contractstatussen worden nu weergegeven als JSON-objecten, waardoor eenvoudige serialisatie in verschillende programmeertalen mogelijk is.

Verbeterde gebruikerservaringen

De nieuwe versie van RGB vereenvoudigt de gebruikerservaring door voorheen uiteenlopende componenten te consolideren in een uniforme bibliotheek-API en opdrachtregeltool.

Hoewel de RGB Node nog steeds op thuisservers kan worden gebruikt, is het gebruik ervan niet langer verplicht voor interactie met het RGB-systeem, waardoor de toegangsdrempel voor gebruikers en portemonnee-applicaties wordt verminderd.

Deze sectie bevat een speciale dank aan Waterdrip Capital voor het onder de aandacht brengen van de nieuwste functies in hun stuk getiteld “Driving Mass Adoption of Crypto: How the RGB Protocol Illuminates the Future of Bitcoin.”

RGB-concurrenten

Figuur 14. FRGB versus Ethereum in eenvoudige bewoordingen.
Bron: LNP/BP Vereniging Github

hoofdwortel

Taproot Assets, voorheen bekend als Taro, is een protocol dat is ontworpen voor het lanceren van tokens op het Bitcoin-netwerk. Dit protocol maakt gebruik van het UTXO-model van Taproot samen met bijbehorende oplossingen zoals Tapscript en taptweak. Deze tools worden gebruikt om informatie over het aanbod en het saldo van een actief op te slaan binnen Bitcoin-transactiegegevens.

Figuur 15. Schema voor het opslaan van informatie over Taproot Assets-tokens.
Bron: “Taproot Assets: het uitgeven van activa op Bitcoin” door Voltage

Taproot Assets maakt gebruik van een methode die analoog is aan het Ordinals-concept, waarbij BRC-20-tokens aanbodinformatie opslaan in de metadata van opgesomde satoshis. Omgekeerd integreren Taproot Assets deze informatie in de Taproot-uitvoer van een Bitcoin-transactie, waarbij gebruik wordt gemaakt van wat bekend staat als een ‘sparse Merkle-boom’. In wezen neemt Taproot Assets een Merkle-boom op in de Bitcoin-transactie, die dient als bewijs van het saldo van een specifieke gebruiker en het totale tokenaanbod. Deze boom weerspiegelt op zijn beurt gegevens uit het ‘Universum’ – een repository die de volledige activageschiedenis bijhoudt en wordt beheerd door de tokenuitgever.

Figuur 16. Digitale statusboom.
Bron: “Taproot Assets: het uitgeven van activa op Bitcoin” door Voltage

State Digital Tree – De architectuur van Taproot Assets biedt twee opties voor balansbewijs: off-chain data uit het universum of de schaarse Merkle-boom ingebed in de UTXO.

Operationeel mechanisme

1. De tokenmaker voert een P2TR-transactie (Pay to Taproot) uit met behulp van het Taproot Assets-protocol. 
2. Informatie over het activum, in de vorm van een Merkle-boom, wordt opgeslagen in de UTXO van deze transactie (in feite het genesisblok). 
3. Om het token over te dragen, wijzigt de eigenaar van de Taproot-sleutel de saldo-informatie in de Merkle-boom, waardoor het totale aanbod van activa constant blijft. 
4. Dergelijke wijzigingen worden geïntroduceerd via een nieuwe Taproot-transactie. Voor elke tokenoverdracht is echter geen afzonderlijke on-chain transactie vereist. Net als bij rollups of het Lightning Network, stelt het protocol de eigenaar in staat een “batch” van overdrachten te verwerken en vervolgens de bijgewerkte stand van de saldi te publiceren.

Voordelen van Taproot-activa

• Een belangrijk voordeel van Taproot Assets is de volledige compatibiliteit met het Lightning Network, waardoor de schaalbaarheidsmogelijkheden worden vergroot en de transactiekosten worden verlaagd.
• Taproot Assets creëert een aparte laag voor het vastleggen van bewerkingen met aangepaste tokens. Hoewel het voornamelijk afhankelijk is van gegevens buiten de keten, maakt het de stand van de saldi op het hoofdnetwerk bekend. 
• Deze aanpak is flexibeler, schaalbaarder en alomvattender dan BRC-20, maar brengt ook meer complexiteit met zich mee voor onervaren gebruikers.

BitVM

BitVM is een geavanceerd project gericht op het transformeren van Bitcoin in een volledig gedecentraliseerd computerplatform. De BitVM-whitepaper, gepresenteerd op 9 oktober 2023, introduceert een technologie die zich momenteel in de testfase bevindt en verdere ontwikkeling vereist om zijn volledige potentieel te bereiken.

Kernfunctionaliteit en concept van BitVM

In de kern gebruikt BitVM het concept van Optimistic Rollups om de berekeningen voor slimme contracten van het netwerk te externaliseren, en vervolgens on-chain verificatie uit te voeren op basis van ‘fraudebewijzen’. Theoretisch gezien is het de bedoeling dat, zodra slimme contractinformatie is vastgelegd in een Taproot-transactie (als binaire code), de gegevensuitwisseling en berekeningen rechtstreeks tussen partijen plaatsvinden. Deze aanpak is ontworpen om de congestie van de blockchain te verminderen. Als de prover (de partij die bewijst, dat wil zeggen de contracteigenaar) echter foutieve gegevens verzendt, kan een verificateur een controle op de keten initiëren. Dit proces vormt de basis van het fraudebestendige concept.

Verificatie in de keten afhandelen in een computationeel beperkt netwerk

De uitdaging ontstaat bij het uitvoeren van een werkingscontrole in een netwerk dat dergelijke berekeningen intrinsiek niet ondersteunt. Om dit aan te pakken, gebruikt BitVM een Merkle-boom om een ​​logisch NAND-poortschema te creëren, dat vervolgens wordt vastgelegd in een Taproot-transactie. In wezen fungeert de Merkle-boom in de transactiegegevens als een NAND-schema, waarbij elke “tak” een van de twee mogelijke waarden heeft: 1 of 0. De on-chain berekening gaat beetje bij beetje verder, waarbij de uitvoer van één “tak” de input voor de volgende. Er vinden voortdurend transactie-uitwisselingen voor waardeverificatie plaats tussen de slimme contractpartijen. Als de berekeningsversie van de prover onjuist wordt bevonden, ontvangt de verificateur zijn activa vergrendeld in de Taproot-transactie.

Figuur 17. Schematische weergave van NAND.
Bron: “The Big Deal with BitVM: Willekeurige berekeningen nu mogelijk op Bitcoin zonder vork” door Bitcoin Magazine

NAND bouwen met behulp van Taproot en Merkle Tree

Gedetailleerde informatie over hoe BitVM het bouwen van NAND vergemakkelijkt met behulp van Taproot- en Merkle-bomen, evenals de impact ervan op berekeningen, is te vinden in de technische documentatie.

Deze aanpak maakt een nauwkeurige, stapsgewijze verificatie van slimme contractberekeningen mogelijk, in lijn met de principes van blockchain-integriteit en -beveiliging.

Uitdagingen met slim contractbilateralisme

Er blijft een aanzienlijk probleem bestaan ​​in BitVM vanwege de bilaterale structuur van slimme contracten, waardoor directe gegevensuitwisseling uitsluitend tussen de verificateur en de prover wordt vergemakkelijkt, met uitsluiting van de betrokkenheid van derden. Deze beperking belemmert de ontwikkeling van dApp en vereist aanvullende oplossingen voor contractconstructies met meerdere partijen. 

Bovendien impliceren de ingewikkelde en laagdrempelige kenmerken van BitVM dat de constructie van functionele producten die gebruik maken van deze basis zich over meerdere jaren kan uitstrekken. Substantiële ontwikkeling en innovatie zijn absoluut noodzakelijk om deze fundamentele technologie in praktische toepassingen te vertalen.

Voor een gedetailleerde diepgaande duik aarzel niet om een ​​BitVM te lezen Whitepaper - https://bitvm.org/bitvm.pdf 

Conclusie

Het RGB-protocol is een technische ontwikkeling in het Bitcoin-ecosysteem en introduceert functionaliteiten voor de implementatie van slimme contracten en de uitgifte van tokens die rechtstreeks verband houden met het Bitcoin-netwerk. Dit wordt bereikt door een combinatie van validatie aan de clientzijde en het gebruik van zegels voor eenmalig gebruik, die tokens koppelen aan de UTXO’s van Bitcoin, terwijl de transactieprivacy behouden blijft.

Een van de belangrijkste technische voordelen van RGB is de benadering van schaalbaarheid en privacy. Door het grootste deel van het validatiewerk van de Bitcoin-blockchain te verplaatsen en cryptografische methoden voor transactieverificatie in te zetten, vermindert RGB effectief de gegevenslast op de blockchain. Deze aanpak is bevorderlijk voor het behoud van de efficiëntie van het netwerk, vooral naarmate de transactievolumes toenemen.

De compatibiliteit van RGB met het Lightning Network is een ander belangrijk aspect, waardoor meer schaalbare en efficiënte transactieverwerking mogelijk is. Deze functie is vooral relevant gezien de groeiende vraag naar snellere en kosteneffectievere transactiemethoden in de cryptocurrency-ruimte.

De complexe aard van de RGB-technologie brengt echter uitdagingen met zich mee op het gebied van toegankelijkheid en begrip voor de gebruiker. De architectuur van het protocol en de gebruikte geavanceerde cryptografische methoden kunnen moeilijk te begrijpen en te implementeren zijn, vooral voor degenen die nieuw zijn met blockchain-technologie. Deze complexiteit zou een bredere adoptie en gebruikersbetrokkenheid kunnen belemmeren.

Hoewel RGB de privacy verbetert door contractgegevens buiten de blockchain te houden, roept dit aspect ook vragen op over de verifieerbaarheid van gegevens en de mogelijkheid om transacties te controleren, die cruciaal zijn voor bepaalde toepassingen en naleving van de regelgeving.

De nieuwste update van RGB, versie 0.10, positioneert het als een opmerkelijke concurrent in het evoluerende landschap van blockchain-technologieën, vooral tegen opkomende protocollen zoals Taproot Assets en BitVM. In tegenstelling tot Taproot Assets, dat zich richt op het benutten van het UTXO-model van Taproot voor de uitgifte van tokens op het Bitcoin-netwerk, onderscheidt RGB zich door zijn geavanceerde privacyfuncties en off-chain gegevensverwerking, waardoor een aparte benadering wordt geboden van slimme contractfunctionaliteit en tokenbeheer.

Terwijl BitVM een nieuw concept introduceert voor gedecentraliseerd computergebruik op Bitcoin, demonstreren RGB's versie 0.10-verbeteringen op het gebied van validatie aan de clientzijde, contractinterfaces en een strikt typesysteem zijn unieke aanpak voor het verbeteren van de schaalbaarheid en gebruikersinteractie binnen het Bitcoin-ecosysteem. Deze verbeteringen benadrukken de bekwaamheid van RGB bij het aanpakken van uitdagingen op het gebied van schaalbaarheid en efficiëntie, gebieden waar traditionele en opkomende protocollen vaak met beperkingen worden geconfronteerd.

De vereenvoudiging van afhankelijkheden en integratieprocessen in de nieuwste versie van RGB duidt verder op een focus op gebruikerservaring en systeemstabiliteit, waardoor het zich onderscheidt van de concurrentie. Dit positioneert RGB niet alleen als een robuust platform voor privacygerichte en schaalbare slimme contracten en tokenuitgifte, maar ook als een vooruitstrevende oplossing in de bredere blockchain-ruimte.

Kortom, het RGB-protocol is een belangrijke technologische ontwikkeling binnen het Bitcoin-netwerk en biedt geavanceerde mogelijkheden voor slimme contracten en token-uitgifte. Het behandelt belangrijke kwesties op het gebied van schaalbaarheid en privacy, maar wordt geconfronteerd met uitdagingen op het gebied van complexiteit en potentiële controleerbaarheid. De voortdurende ontwikkeling en toekomstige iteraties van het protocol zullen zich waarschijnlijk richten op het balanceren van deze geavanceerde mogelijkheden met gebruikerstoegankelijkheid en regelgevingsoverwegingen.

Termijnreferenties: 

1. Turing compleet: In praktische termen kan het systeem elk rekenprobleem uitvoeren met voldoende tijd en geheugen. De meeste moderne programmeertalen zijn Turing-compleet, wat duidt op hun theoretische vermogen om elk computerprobleem aan te pakken.
   
2. Schema: Een contractschema dient als de daadwerkelijke code voor een slim contract, dat door de uitgevers als ‘contractsjabloon’ kan worden gebruikt zonder de noodzaak van het coderen of controleren van aangepaste code die door externe bronnen wordt aangeleverd. RGB-schema is geen script maar een datastructuur.
   
3. Discrete logcontracten (DLC's) in de context van staatskanalen zijn gespecialiseerde slimme contracten die voornamelijk in het Bitcoin-netwerk worden gebruikt. Ze maken een private en efficiënte uitvoering mogelijk van complexe financiële overeenkomsten op basis van externe gebeurtenissen, zoals activaprijzen. DLC's werken off-chain en handhaven de vertrouwelijkheid van contractgegevens en identiteiten van deelnemers. Ze maken gebruik van externe gegevensbronnen, of orakels, voor het oplossen van contracten. Wanneer ze worden geïntegreerd met staatskanalen, verbeteren DLC's de schaalbaarheid door meerdere transactieafwikkelingen mogelijk te maken zonder de blockchain te verstoppen, waardoor ze ideaal zijn voor particuliere, efficiënte financiële transacties die afhankelijk zijn van resultaten in de echte wereld.
   
4. Storm – op escrow gebaseerde, betrouwbare opslag met behulp van zk-proofs. Storm combineert op escrow gebaseerde, betrouwbare opslag met zero-knowledge proofs om veilige en privétransacties mogelijk te maken. In dit systeem worden gegevens of activa in bewaring gehouden en pas vrijgegeven als aan specifieke voorwaarden wordt voldaan, waardoor een betrouwbare omgeving wordt gegarandeerd waarin geen centrale autoriteit nodig is. De integratie van zk-proofs maakt de verificatie van deze transacties mogelijk met behoud van de grootst mogelijke vertrouwelijkheid, aangezien ze de validatie van gegevens mogelijk maken zonder onderliggende details prijs te geven.
   
5. Prometheus – op arbitrage gebaseerd, betrouwbaar gedistribueerd computergebruik. Prometheus vertegenwoordigt een benadering van gedecentraliseerd computergebruik, waarbij arbitragemechanismen voor geschillenbeslechting, betrouwbare interacties voor veilige en gedecentraliseerde operaties en de efficiëntie van staatskanalen voor off-chain computerbeheer worden gecombineerd.
   
6. A Computer met beperkte instructieset is een type microprocessorarchitectuur die gebruik maakt van een kleine, zeer geoptimaliseerde set instructies in plaats van de zeer gespecialiseerde set instructies die doorgaans in andere architecturen wordt aangetroffen.