RGB styrker Bitcoin og Lightning Networks skalerbarhed og privatlivsfunktioner

TL; DR

• RGB fungerer som en Layer 2/3-løsning på Bitcoin og Lightning Network.client-side valideringsparadigmet, der rummer alle smarte kontraktdata uden for Bitcoin-transaktioner. Dette design sikrer systemets drift oven på Lightning Network, hvilket eliminerer behovet for ændringer af LN-protokoller.
  
• RGB smarte kontrakter er designet til skalerbarhed og fortrolighed. Systemet understøtter privat og gensidigt ejerskab, abstraherer og adskiller bekymringer, hvilket repræsenterer en post-blockchain, Turing-komplet form for tillidsfri distribueret computing uden at det er nødvendigt at introducere nye tokens.
  
• RGB-kontrakter er organiseret i separate segmenter kaldet "shards", hver med sin egen historie og data, hvilket forbedrer skalerbarheden og forhindrer blanding af historier fra forskellige kontrakter. De interagerer via Bifrost-protokollen på Lightning Network, hvilket muliggør koordinerede ændringer mellem flere parter, svarende til DEX'er, der opererer på Lightning Network.
  
• RGB anvender engangstætninger defined over Bitcoin UTXO'er for sikkerhed. Enhver part, der besidder en intelligent kontraktstatshistorie, kan verificere dens unikhed ved at udnytte Bitcoins script til define ejerskab og adgangsrettigheder.
  
• I RGB er statens ejerskab og validering separate enheder. Ejerskab administreres af Bitcoin-scriptet, et ikke-Turing Complete-system. Valideringsregler er på den anden side dikteret af RGB-skemaet ved hjælp af Turing Complete Simplicity/Contractum/Rust Script.
  
• Hver RGB smart kontrakt er forbundet med en unik tilstand ved hjælp af engangs segl. Seglerne og staten følger specifikke regler og valideringer fastsat af kontraktens skaber, styret af et "skema". Dette skema fungerer som et regelsæt til kontrol af kontraktdata på klientsiden, hvilket muliggør et højt niveau af protokolskalerbarhed og privatliv.
  
• RGBs design er yderst interoperabelt med eksisterende Bitcoin- og Lightning Network-teknologier, hvilket letter problemfri integration med disse platforme og eventuelle fremtidige opgraderinger.
  
• I modsætning til den imperative programmeringsstil på mange blockchain-platforme, anvender RGB en deklarativ stil. Denne tilgang fokuserer på at skitsere det ønskede resultat i stedet for at beskrive de specifikke trin for at opnå det.
  
• RGB anvender forskellige avancerede teknologier, herunder AluVM til deterministiske bærbare computeropgaver, PRISM til delvist replikerede uendelige tilstandsmaskiner og Storm til escrow-baseret trustless storage ved hjælp af zk-proofs. Disse teknologier bidrager til RGBs robusthed, fortrolighed og udvidelsesmuligheder.
  
• RGB (v0.10) introducerer bemærkelsesværdige forbedringer til brugeroplevelse og integrationsprocesser, strømliner driften og minimerer afhængigheder. Den opdaterede version har et mere samlet biblioteks-API og et kommandolinjeværktøj, hvilket gør det mere tilgængeligt og brugervenligt.

Kort beskrivelse

RGB er en protokol designet til at udstede tokens på Bitcoin-netværket med forbedret privatliv og kompatibilitet med Lightning Network. Det bygger på konceptet "farvede mønter", som dem, der bruges i OmniLayer-protokollen, hvor metadata i Bitcoin-transaktioner indikerer en token-overførsel. For eksempel fungerer USDT-transaktioner på OmniLayer som Bitcoin-transaktioner suppleret med yderligere data, der beskriver USDT-tokens bevægelser. Disse metoder står imidlertid over for begrænsninger såsom datastørrelsesbegrænsninger i OP_RETURN-output, intensiv blockchain-scanning og begrænset privatliv, der stammer fra synlighed i kæden.

RGB løser disse problemer ved at flytte størstedelen af ​​valideringsprocesserne væk fra Bitcoin blockchain. Den anvender validering på klientsiden og anvender engangsforseglinger til at forbinde tokens med Bitcoins UTXO'er, alt imens brugernes privatliv bevares.

Tokens overføres ved at forpligte sig til en meddelelse, der indeholder RGB-betalingsoplysninger inden for en Bitcoin-transaktion, hvilket gør det muligt for tokens at flytte fra en UTXO til en anden uden at efterlade et spor på Bitcoin-transaktionsgrafen. Dette forbedrer privatlivets fred betydeligt, da RGB-transaktioner "teleporterer" tokens diskret med RGB-specifikke data, der sendes gennem private off-chain-kanaler.

For at sikre ejerskab og forhindre inflation skal modtagere desuden validere hele transaktionshistorikken for de modtagne tokens. RGB muliggør fremtidige opgraderinger uden behov for hårde gafler, hvilket sikrer, at minearbejdere ikke er i stand til at spore aktivflow, hvilket giver en højere modstand mod censur. I modsætning til traditionelle blockchain-strukturer fungerer RGB uden behov for blokke eller kæder, og placerer det som en ikke-blok decentral protokol, der lover høj fortrolighed, sikkerhed og skalerbarhed.

Introduktion og vision

One-liner: Et klientvalideret tilstand og smart-kontrakt system, der opererer på Layer 2/3 i Bitcoin og Lightning Network.

Flere detaljer:

RGB er et skalerbart og fortroligt smart kontraktsystem til Bitcoin & Lightning Network. RGB smarte kontrakter opererer med validering på klientsiden paradigme, bolig alle smarte kontraktdata udenfor Bitcoin-transaktioner, dvs. Bitcoin blockchain eller Lightning-kanaltilstand. Dette gør det muligt for systemet at fungere oven på Lightning Network uden ændringer i LN-protokollerne og giver også et grundlag for et højt niveau af protokolskalerbarhed og privatliv.

Smarte kontrakter omfatter principper om privat og gensidigt ejerskab, abstraktion og adskillelse af bekymringer. De repræsenterer en "post-blockchain", Turing-komplet form for tillidsfri distribueret computer, der ikke kræver introduktion af tokens.

RGB-kontrakter opererer i separate segmenter kaldet "shards". Hvert shard har sin egen historie og data, hvilket betyder, at forskellige kontrakter ikke blander deres historie. Denne metode forbedrer skalerbarheden. Udtrykket "shard" bruges til at vise, at RGB opnår lignende mål, som det var tilsigtet med Ethereums shards-koncept.

Selvom de fungerer uafhængigt, kan RGB-kontrakter interagere gennem Bifrost-protokollen på Lightning Network. Dette giver mulighed for koordinerede ændringer mellem flere parter. For eksempel gør det DEX'er i stand til at fungere over Lightning-netværket.

Teknologi & Arkitektur

Oversigt på højt niveau over RGB-drift og engangstætninger

Figur 1. Oversigt på højt niveau over driften af ​​RGB.
Kilde: LNP/BP Association Github.

Som en sikkerhedsmekanisme bruger RGB engangsplomber defined over bitcoin UTXO'er, som giver mulighed for enhver part, der har en smart kontraktstatushistorie, til at verificere dens unikhed. I det væsentlige udnytter RGB Bitcoin script til sin sikkerhedsmodel og defiian ejerskab , adgangsrettigheder.

Figur 2. RGB Arbejdsprincip på højt niveau.
Kilde: "Driving Mass Adoption of Crypto: How the RGB Protocol is Illuminating the Future of Bitcoin" af Waterdrip Capital.

Hver RGB smart kontrakt er defined af en tilblivelsestilstand, udformet af smart kontraktudsteder (eller forenklet sagt udsteder) og en rettet acyklisk graf (DAG) af tilstandsovergange vedligeholdes som klientvaliderede data.

Figur 3. Transaktioner, lukket segl og vidne.
Kilde: LNP/BP Association Github.

Vi kan opsummere det som følger: hver transaktion har en UTXO, og ejerskab af denne UTXO giver ejeren ret til at besidde staten. Ejerskab bestemmer, hvem der kan ændre blockchain-tilstanden og "bruge" UTXO. Den person, der holder staten, betegnes som part ejerstat.

Parten har beføjelsen til at ændre den relevante del af den intelligente kontrakttilstand ved at generere en ny tilstandsovergang og bekræfte den i en transaktion ved at bruge outputtet, der indeholder den tidligere tilstand.

Processen betyder lukning af et segl over tilstandsovergangen, og et par, der omfatter forbrugstransaktionen og tilsvarende ekstratransaktionsdata om tilstandsovergangen, betegnes som en vidne (afbildet på billedet ovenfor).

Ejerskab og adgang: Kerneegenskaber

Figur 4. Ejerskab og adgang.
Kilde: LNP/BP Association Github.

Statens ejerskab og validering er adskilte begreber. Valideringsregler angiver, hvordan staten kan ændre sig, mens de ikke identificerer, hvem der kan effektuere ændringen. 

På den anden side styres ejerskabet af Bitcoin script på Bitcoin blockchain niveau, hvilket ikke er Turing Complete. I modsætning hertil er valideringsregler styret af RGB-skemaet, der bruger Simplicity/Contractum Script, dvs. at være Turing Complete. 

RGB-skema

I RGB smarte kontrakter tildeles hver kontrakt en unik tilstand gennem engangsplomber. Disse segl har sammen med staten specifikke regler og valideringer, fastsat af kontraktens skaber i begyndelsen. Denne opsætning er styret af et "skema", der fungerer som et sæt regler til at validere kontraktdata på klientsiden. Skemaet kan omfatte komplekse scripts, der er integreret i kontraktens logik.

Figur 5. RGB-skema.
Kilde: LNP/BP Association Github.

Kundesidens validering og designprincipper

Figur 6. RGB Client-side-validation.
Kilde: LNP/BP Association Github.

1. Stærkt ejerskab: I RGB har smarte kontrakter et klart defined ejer eller ejere. Kun udpegede ejere har beføjelsen til at ændre kontraktens tilstand. Disse kontrakter beskriver særskilte rettigheder eller operationer kategoriseret som enten offentlige (tilgængelige for alle) eller ejede (begrænset til ejeren).
2. Fortrolighed: Oplysninger i kontrakten holdes fortrolige, kun kendt af deltagerne, især ejerne af staten. Deltagere har mulighed for at offentliggøre visse data, men som standard er alle oplysninger private. Denne fortrolighed forhindrer eksterne analyseværktøjer i at få adgang til dataene og sikrer, at der ikke gemmes følsomme oplysninger i offentlige finanser.
3. Adskillelse af bekymringer: RGB har et modulært design med særskilte lag, der hver er tildelt en specifik opgave. Disse lag fungerer uafhængigt, hvilket eliminerer nødvendigheden af, at lavere lag er opmærksomme på de højere lags struktur. Dette design forbedrer organisationen og effektiviteten af ​​systemet.
4. udvidelsesmuligheder: Systemet kan nemt udvides, hvilket giver mulighed for oprettelse og integration af avancerede smarte kontrakter uden at det er nødvendigt at ændre kerneprotokollen eller genkompilere hele RGB-biblioteket.
5. Determinisme: RGBs valideringslogik er deterministisk og giver konsekvent identiske resultater med de samme input og den fremherskende tilstand af underliggende blockchain eller Lightning Network-kanal. Denne sammenhæng opnås gennem to hovedkomponenter: a. Kernevalideringslogikken, skrevet i Rust, er den samme på tværs af alle systemer, der kører RGB. b. Kontraktspecifik valideringslogik kører på AluVM, en virtuel maskine, der giver et ensartet sæt instruktioner uanset platformen.
6. LNP/BP interoperabilitet: RGB er designet til at fungere problemfrit med eksisterende Bitcoin- og Lightning Network-teknologier. Den er også bygget til at være kompatibel med fremtidige opgraderinger til disse teknologier.
   

Tilgang til RGB og Pure Blockchain/L1 tilgang

Ren blockchain/L1-tilgang er forkert, fastslår RGB-teamet.

Figur 7. RGB kommentarer til Blockchain/L1 tilgang.
Kilde: LNP/BP Association Github.

RGB's tilgang: Deklarativ vs. imperativ programmering:

• De fleste blockchain-platforme, inklusive Ethereum, bruger smarte kontrakter skrevet i en imperativ stil. I denne tilgang fungerer kontrakten som et program, der eksplicit leder den trinvise udførelse af opgaver, der ligner en præcis og detaljeret opskrift.
• Disse imperative programmer er ofte ret restriktive og begrænset af mulighederne i den underliggende blockchain-platform. Selvom de nogle gange omtales som Turing-komplet, kommer de med betydelige begrænsninger.

Deklarativ karakter af RGB Smart-kontrakter:

• RGB, på den anden side, bruger ikke tvingende programmering. I stedet anvender den en særlig form for funktionel programmering, hvor smarte kontrakter er defined deklarativt.
• I deklarativ programmering beskriver du i stedet for at detaljere, hvordan man gør noget, hvad resultatet skal være. Det er som at skitsere, hvordan et måltid skal se ud i stedet for at give trinvise tilberedningsinstruktioner.
• "Skemaet" i RGB er et deklarativt defien smart kontrakt. Den specificerer reglerne og betingelserne for kontrakten, men ikke den nøjagtige rækkefølge af operationer for at opnå dem.

Paradigmeskift i programmering:

• At flytte fra Ethereums imperative stil til RGBs deklarative stil inden for smart kontraktprogrammering svarer til skiftet fra traditionel imperativ programmering til funktionel eller deklarativ programmering i generel softwareudvikling.
• Dette skift kræver en anden tankegang: at fokusere på "hvad" (de ønskede resultater) snarere end "hvordan" (de specifikke trin for at opnå disse resultater).

Enkelhed

Den oprindelige plan indebar at inkorporere Simplicity i RGB, og indsatsen var dedikeret til at sikre kompatibilitet fra dag 1. Men i betragtning af den træge udvikling af Simplicity-udviklingen og usikkerheden omkring dens udgivelsestidslinje, blev det tydeligt, at det var upraktisk at stole på det. Den igangværende RGB-udgivelse, som i øjeblikket er under forberedelse, rejste spørgsmål om Simplicitys inklusion.

I erkendelse af fraværet af en pålidelig tidsplan for Simplicity, indledte vi en undersøgelse af alternativer (WASM, EVM (som en joke), IELE osv.). Til sidst blev det klart, at udvikling af en proprietær virtuel maskine til RGB var den eneste levedygtige mulighed, der erstattede den oprindelige afhængighed af Simplicity.

Derfor besluttede vi at skabe AluVM – ren funktionel, meget bærbar Rust-baseret virtuel maskine til klientside-validerede smarte kontrakter (RGB), Lightning Network, deterministisk distribueret og edge computing.

Prisme

PRISM står for "partially-replicated infinite state machines" computing.

RGB teknologi defines regler for udvikling af smarte kontrakter på et grundlæggende niveau, kaldet Schema, men det begrænser ikke alle fremtidige handlinger af kontrakten med en enkelt, overordnet algoritme. I stedet udfører hver node på netværket individuelle operationer, og både kontraktens tilstand og selve kontrakten forbliver gyldige, så længe disse operationer overholder skemaets regler. 

Desuden begrænser denne tilgang ikke kontraktens historiske udvikling med en forudbestemt algoritme. En kontrakt kan således udvise varieret adfærd, så længe hver ændring opfylder specifikke valideringsregler. Denne metode fokuserer på lokale regler frem for en global algoritme.

I modsætning hertil bruger Ethereum en global algoritme, hvor hver operation påvirker hele tilstanden af ​​den smarte kontrakt. Med RGB arbejder du kun med en del af kontraktens tilstand og anvender regler lokalt. Dette giver en bredere vifte af muligheder for kontraktudvikling.

Nedenfor kan du se et overblik over forskellene mellem statskanaler og validering på klientsiden: 

Figur 8. Distribuerede systemer adskillelse.
Kilde: LNP/BP Association Github.

Mere specifikke forskelle er som følger: 

Figur 9. Sammenligning af statskanaler og validering på klientsiden.
Kilde: LNP/BP Association Github.

AluVM

AluVM – (algoritmisk logisk enhed VM) er en ren og funktionel virtuel RISC-maskine designet til deterministiske bærbare computeropgaver

AluVM udmærker sig ved at anvende et registerbaseret system, der forbyder tilfældig hukommelsesadgang. Dette design forbedrer AluVMs egnethed til applikationer såsom smarte kontrakter, fjernudførelse af kode og distribueret og edge computing. Kernestyrkerne ved AluVM ligger i dens determinisme, robusthed og kapacitet til formel kodeanalyse.

Nøglekarakteristika: Exceptionless, Portabilitet, Sandboxing, Sikkerhed, Udvidelsesmuligheder.

Instruction Set Architecture (ISA) af AluVM er designet til at være tilpasningsdygtig, så den kan skabe forskellige runtime-miljøer til forskellige applikationer. AluVM i sig selv er en yderst forudsigelig, funktionel, registerbaseret virtuel maskine og ISA. 

Mens den begrænser tilfældig hukommelsesadgang, udmærker AluVM ISA sig i at udføre aritmetiske opgaver, herunder dem, der er relateret til elliptiske kurver. Entydigt kan VM's miljø udvide AluVM ISA, hvilket muliggør tilføjelse af funktionaliteter såsom indlæsning af data i VM's registre og understøttelse af specialiserede instruktioner (f.eks. SIMD) skræddersyet til specifikke applikationer.

AluVM er hovedsageligt beregnet til brug i distribuerede systemer, hvor konsistens og pålidelighed på tværs af forskellige platforme er mere afgørende end behandlingshastighed. De primære anvendelser for AluVM, med de rigtige ISA-udvidelser, inkluderer blockchain-teknologi, beregninger, der er kritiske for konsensus i netværk, edge computing, multiparty computing (som dækker deterministisk maskinlæring), klient-side-validering, begrænset Internet2 computing og genetiske algoritmer. Disse applikationer drager fordel af AluVM's evne til at udføre konsekvent og sikkert i forskellige miljøer.

Figur 10. AluVM-sammenligning.
Kilde: LNP/BP Association Github.

Contractum

Contractum adskiller sig fra andre smarte kontraktprogrammeringssprog ved at blande Haskells funktionelle muligheder med nærheden til det nøgne metal, som ses i Rust. Det indtager en niche, der tidligere var utilgængelig for smarte kontrakter:

Figur 11. Sammenligning af Contractum, Simplicity og andre sprog.
Kilde: contractum.org

Contractum er et programmeringssprog, der bruges til at oprette RGB-kontrakter. Kontrakter indgået med Contractum kontrolleres ved hjælp af en metode kaldet klientside-validering. Denne tilgang tilføjer ingen data til Bitcoin blockchain, som kan sammenlignes med en form for sharding teknologi, yderligere forbedret med brugen af ​​nul-viden beviser. 

Klient-side-validering adskiller også kontraktens udvikling fra blockchain-transaktioner, hvilket gør det umuligt at spore eller analysere disse transaktioner gennem traditionelle blockchain-analysemetoder.

Figur 12. Contractum funktioner.
Kilde: contractum.org

For at deltage i Contractum-design er det vigtigt at sætte dig ind i de teknologier, der anvendes af RGB smart contracts:

Figur 13. Teknologier, der bruges af RGB smarte kontrakter.
Kilde: contractum.org

Seneste opdateringer i ny version RGB v0.10

I den seneste iteration af RGB (version 0.10) er adskillige avancerede tekniske forbedringer blevet implementeret, hvilket forbedrer rammernes muligheder for kompleks applikationsudvikling. Disse opdateringer fokuserer primært på indførelse af en global stat for hver RGB-kontrakt, integration af kontraktgrænseflader og indførelse af et strengt typesystem.

Global tilstand i RGB-kontrakter

Global State-funktionen er en kritisk innovation i RGB v0.10, der gør det muligt for hver kontrakt at opretholde en universelt tilgængelig tilstand. Denne tilstand er ikke kun tilgængelig for den virtuelle RGB-maskine, men også for eksterne klienter såsom tegnebøger og andre applikationer.

Nytten af ​​denne Global State er afgørende for at konstruere sofistikerede applikationer på RGB-platformen, især dem, der kræver indviklet tilstandsstyring som syntetiske aktiver og algoritmiske stablecoins. Det giver mulighed for en mere dynamisk interaktion med kontraktens tilstand, der strækker sig ud over begrænsningerne for traditionelle smarte kontraktarkitekturer.

Kontraktgrænseflader

RGB v0.10 introducerer 'kontraktgrænseflader' som en standardiseret kommunikationsprotokol til forskellige smarte kontrakter. Disse grænseflader fungerer på samme måde som Ethereums kontrakt ABI'er (Application Binary Interfaces) og ERC'er (Ethereum Request for Comments).

En vigtig skelnen ved RGB's tilgang er den ikke-obligatoriske standardisering af disse grænseflader og deres iboende pakning med kontrakter, hvilket eliminerer behovet for separat distribution. Dette letter semantisk-bevidste interaktioner mellem brugere og kontrakter via brugergrænseflader i tegnebøger og anden software.

Disse grænseflader er ikke statiske; Udviklere kan udvide eksisterende kontrakter med yderligere grænseflader over tid, hvilket forbedrer funktionaliteten uden at ændre den uforanderlige kontraktkerne.

Streng type system

Det nye kodningsformat i RGB v0.10 bruger et 'strenge typer'-system. Dette system er en ny funktionel datatypetilgang designet til effektiv repræsentation og introspektion af kontrakttilstande inden for RGB-rammen.

Det strenge typesystem sikrer kompileringstidssikring af datastørrelser, hvilket er særligt fordelagtigt til drift på ressourcebegrænsede enheder, såsom low-end hardware-punge med begrænsede hukommelseskapaciteter.

Desuden er hele RGB-konsensuslaget i version 0.10 kompileret i strenge typer, hvilket giver et grundlag for formelle beviser for binær kompatibilitet på tværs af forskellige softwareudgivelser. Denne funktion forenkler og sikrer ikke kun brugen af ​​RGB, men gør det også muligt for aktivudstedere og kontraktudviklere at tilføje yderligere metadata til deres aktiver eller kontrakter. Sådanne metadata kan spille en afgørende rolle i at verificere identiteten og ægtheden af ​​aktiver eller kontrakter i RGB-økosystemet.

Rustbaserede smarte kontrakter

RGB smarte kontrakter kan nu oprettes i Rust, der udnytter sprogets muligheder for typesikkerhed og ydeevne.

Den strenge systemtypeintegration letter den direkte kompilering af Rust-datatyper i RGB-kontraktstrukturer, hvilket forbedrer effektiviteten og pålideligheden af ​​kontraktkoden.

Forbedrede statslige introspektionskapaciteter

Smarte kontrakter i RGB v0.10 kan introspektere deres egen tilstand inden for valideringskoden, der udføres af den virtuelle RGB-maskine.

Denne funktion er især nyttig til at skabe komplekse kontrakter, der interagerer med Bitcoin-transaktioner, Diskrete Log-kontrakter og andre indviklede datastrukturer, hvilket forbedrer omfanget og funktionaliteten af ​​RGB-smarte kontrakter.

URL-baseret fakturaformat

Opdateringen introducerer et nyt fakturaformat, der erstatter det tidligere Bech32m-kodede system.

Disse nye URL-baserede fakturaer er væsentligt kortere og mere brugervenlige, hvilket letter verifikation og automatisk åbning med forudkonfigureret software.

WASM (WebAssembly) Support

RGB-standardbiblioteket er nu kompatibelt med miljøer, der mangler I/O- og filsystemadgang, såsom websider eller browser-plugins.

Dette udvider de potentielle anvendelsesmuligheder for RGB, så det kan fungere problemfrit i en lang række webbaserede applikationer og udvidelser.

Pælerodsbeskrivelser og tilpasset afledning

RGB v0.10 bruger taproot-baserede OP_RETURN-forpligtelser (benævnt tapret), hvilket nødvendiggør support på deskriptorniveau for tegnebøger til at genkende transaktioner med tweakede output.

Introduktionen af ​​brugerdefinerede afledningsindekser i denne version forhindrer ikke-RGB-tegnebøger i utilsigtet at bruge output, der indeholder RGB-aktiver, og derved sikre integriteten af ​​disse aktiver.

Forenklede afhængigheder

RGB-konsensuslaget i version 0.10 har reduceret dets afhængigheder, især ved at bevæge sig væk fra en brugerdefineret skudsikker implementering, der oprindeligt stammer fra Grin-projekter.

Denne reduktion i afhængigheder forbedrer API'ens stabilitet og overordnede system robusthed.

Strømlinet integrationsproces

Opdateringen forenkler operationelle arbejdsgange ved at reducere behovet for flere API-kald og kompleks datastrukturkodning på tværs af sprog.

RGB-kontrakttilstande er nu repræsenteret som JSON-objekter, hvilket muliggør ligetil serialisering på tværs af forskellige programmeringssprog.

Brugeroplevelse forbedringer

Den nye version af RGB forenkler brugeroplevelsen ved at konsolidere tidligere forskellige komponenter i et samlet biblioteks-API og kommandolinjeværktøj.

Mens RGB Node stadig kan betjenes på hjemmeservere, er brugen ikke længere obligatorisk for at interagere med RGB-systemet, hvilket reducerer adgangsbarrieren for brugere og tegnebogsapplikationer.

Dette afsnit inkluderer en særlig anerkendelse til Waterdrip Capital for at sætte fokus på de seneste funktioner i deres stykke med titlen "Driving Mass Adoption of Crypto: How the RGB Protocol Illuminates the Future of Bitcoin."

RGB-konkurrenter

Figur 14. FRGB vs Ethereum i simple ord.
Kilde: LNP/BP Association Github

pælerod

Taproot Assets, tidligere kendt som Taro, er en protokol designet til at lancere tokens på Bitcoin-netværket. Denne protokol udnytter UTXO-modellen af ​​Taproot sammen med tilhørende løsninger som Tapscript og taptweak. Disse værktøjer bruges til at gemme oplysninger om forsyningen og balancen af ​​et aktiv i Bitcoin-transaktionsdata.

Figur 15. Skema til lagring af information om Taproot Assets-tokens.
Kilde: "Taproot Assets: Issuing assets on Bitcoin" af Voltage

Taproot Assets anvender en metode, der er analog med Ordinals-konceptet, hvor BRC-20-tokens gemmer forsyningsinformation i metadataene for opregnede satoshis. Omvendt indlejrer Taproot Assets denne information i en Bitcoin-transaktions Taproot-output ved at bruge det, der er kendt som et "sparsomt Merkle-træ". I det væsentlige inkorporerer Taproot Assets et Merkle-træ i Bitcoin-transaktionen, som tjener som bevis på en specifik brugers balance og den samlede token-forsyning. Dette træ afspejler til gengæld data fra "Universet" - et lager, der vedligeholder hele aktivhistorien og administreres af token-udstederen.

Figur 16. Digitalt tilstandstræ.
Kilde: "Taproot Assets: Issuing assets on Bitcoin" af Voltage

State Digital Tree - Arkitekturen af ​​Taproot Assets tilbyder to muligheder for balancebevis: off-chain data fra universet eller det sparsomme Merkle-træ, der er indlejret i UTXO.

Operationel mekanisme

1. Token-skaberen udfører en P2TR-transaktion (Pay to Taproot) ved hjælp af Taproot Assets-protokollen. 
2. Oplysninger om aktivet, i form af et Merkle-træ, gemmes i denne transaktions UTXO (reelt set genesis-blokken). 
3. For at overføre tokenet ændrer ejeren af ​​Taproot-nøglen balanceoplysningerne i Merkle-træet, hvilket sikrer, at den samlede aktivforsyning forbliver konstant. 
4. Sådanne ændringer introduceres via en ny Taproot-transaktion. For hver token-overførsel kræves der dog ikke en separat on-chain-transaktion. I lighed med rollups eller Lightning Network giver protokollen ejeren mulighed for at behandle en "batch" af overførsler og efterfølgende offentliggøre den opdaterede status for saldi.

Fordele ved pælerodsaktiver

• En vigtig fordel ved Taproot Assets er dens fulde kompatibilitet med Lightning Network, hvilket forbedrer skalerbarhedsmulighederne og reducerer transaktionsomkostningerne.
• Taproot Assets opretter et særskilt lag til optagelse af operationer med brugerdefinerede tokens. Mens den primært er afhængig af off-chain data, offentliggør den status for saldi på hovednetværket. 
• Denne tilgang er mere fleksibel, skalerbar og omfattende sammenlignet med BRC-20, men den udgør også mere kompleksitet for uerfarne brugere.

BitVM

BitVM er et banebrydende projekt, der har til formål at transformere Bitcoin til en fuldt decentraliseret computerplatform. BitVM-hvidbogen blev præsenteret den 9. oktober 2023 og introducerer en teknologi, der i øjeblikket er i testfasen og kræver yderligere udvikling for at nå sit fulde potentiale.

Kernefunktionalitet og koncept for BitVM

I sin kerne anvender BitVM konceptet med Optimistic Rollups til at eksternalisere beregningerne for smarte kontrakter fra netværket, og udfører efterfølgende on-chain-verifikation baseret på "fraud proofs." Teoretisk set er det meningen, at dataudveksling og beregninger skal ske direkte mellem parterne, når først smart kontraktinformation er registreret i en Taproot-transaktion (som binær kode). Denne tilgang er designet til at reducere blockchain-overbelastning. Men hvis beviseren (den part, der beviser, dvs. kontraktejeren) transmitterer fejlagtige data, kan en verifikator påbegynde et on-chain-tjek. Denne proces danner grundlaget for fraud proof-konceptet.

Håndtering af on-chain verifikation i et beregningsmæssigt begrænset netværk

Udfordringen opstår i, hvordan man udfører et operationstjek i et netværk, der i sig selv ikke understøtter sådanne beregninger. For at løse dette bruger BitVM et Merkle-træ til at skabe et logisk NAND-gateskema, som derefter registreres i en Taproot-transaktion. I det væsentlige fungerer Merkle-træet i transaktionsdataene som et NAND-skema, hvor hver "gren" bærer en af ​​to mulige værdier: 1 eller 0. On-chain-beregningen fortsætter bit for bit, hvor outputtet fra en "gren" bliver til input til det næste. Konstante transaktionsudvekslinger til værdibekræftelse forekommer mellem de smarte kontraktparter. Hvis bevisgiverens beregningsversion findes forkert, modtager verifikatoren deres aktiver låst i Taproot-transaktionen.

Figur 17. Skematisk repræsentation af NAND.
Kilde: "The Big Deal with BitVM: Arbitrary Computation now possible on Bitcoin without a fork" af Bitcoin Magazine

Opbygning af NAND ved hjælp af pælerod og Merkle-træ

Detaljeret information om, hvordan BitVM letter opbygningen af ​​NAND ved hjælp af Taproot- og Merkle-træer, samt dets indvirkning på beregninger, kan findes i den tekniske dokumentation.

Denne tilgang giver mulighed for en præcis, trin-for-trin verifikation af intelligente kontraktberegninger, der er i overensstemmelse med principperne om blockchain-integritet og sikkerhed.

Udfordringer med Smart Contract Bilateralism

Et væsentligt problem er fortsat i BitVM på grund af den bilaterale struktur af smarte kontrakter, der letter direkte dataudveksling udelukkende mellem verifikatoren og beviseren, undtagen involvering af tredjeparter. Denne begrænsning hæmmer dApp-udvikling og kræver supplerende løsninger til flerpartskontraktkonstruktioner. 

Ydermere indebærer BitVM's indviklede og lave egenskaber, at konstruktionen af ​​funktionelle produkter, der udnytter dette fundament, kan strække sig over flere år. Væsentlig udvikling og innovation er afgørende for at omsætte denne grundlæggende teknologi til praktiske anvendelser.

For et detaljeret dybt dyk, tøv ikke med at læse en BitVM Whitepaper - https://bitvm.org/bitvm.pdf 

Konklusion

RGB-protokollen er en teknisk udvikling i Bitcoin-økosystemet, der introducerer funktionaliteter til smart kontraktimplementering og tokenudstedelse direkte knyttet til Bitcoin-netværket. Dette opnås gennem en kombination af validering på klientsiden og brug af engangsforseglinger, som forbinder tokens til Bitcoins UTXO'er, mens transaktionens privatliv bevares.

En af de primære tekniske fordele ved RGB er dens tilgang til skalerbarhed og privatliv. Ved at flytte hovedparten af ​​valideringsarbejdet væk fra Bitcoin blockchain og anvende kryptografiske metoder til transaktionsverifikation reducerer RGB effektivt databyrden på blockchain. Denne tilgang er befordrende for at opretholde netværkets effektivitet, især når transaktionsvolumen stiger.

RGBs kompatibilitet med Lightning Network er et andet væsentligt aspekt, der muliggør mere skalerbar og effektiv transaktionsbehandling. Denne funktion er særlig relevant i betragtning af den stigende efterspørgsel efter hurtigere og mere omkostningseffektive transaktionsmetoder i kryptovaluta-området.

Den komplekse karakter af RGB’s teknologi giver dog udfordringer med hensyn til brugertilgængelighed og -forståelse. Protokollens arkitektur og de avancerede kryptografiske metoder, der anvendes, kan være vanskelige at forstå og implementere, især for dem, der er nye til blockchain-teknologi. Denne kompleksitet kan hindre en bredere anvendelse og brugerengagement.

Derudover, mens RGB forbedrer privatlivets fred ved at holde kontraktdata væk fra blockchain, rejser dette aspekt også spørgsmål om dataverificerbarhed og evnen til at revidere transaktioner, hvilket er afgørende for visse applikationer og lovoverholdelse.

RGBs seneste opdatering, version 0.10, positionerer den som en bemærkelsesværdig konkurrent i det udviklende landskab af blockchain-teknologier, især mod nye protokoller som Taproot Assets og BitVM. I modsætning til Taproot Assets, som fokuserer på at udnytte UTXO-modellen af ​​Taproot til tokenudstedelse på Bitcoin-netværket, udmærker RGB sig med sine avancerede privatlivsfunktioner og off-chain datahåndtering, der tilbyder en særskilt tilgang til smart kontraktfunktionalitet og token-styring.

På samme måde, mens BitVM introducerer et nyt koncept for decentraliseret databehandling på Bitcoin, fremviser RGBs version 0.10 fremskridt inden for klientsidevalidering, kontraktgrænseflader og et strengt typesystem dets unikke tilgang til at forbedre skalerbarhed og brugerinteraktion i Bitcoin-økosystemet. Disse forbedringer fremhæver RGB's dygtighed til at håndtere skalerbarheds- og effektivitetsudfordringer, områder hvor traditionelle og nye protokoller ofte står over for begrænsninger.

Forenklingen af ​​afhængigheder og integrationsprocesser i RGBs seneste version indikerer yderligere et fokus på brugeroplevelse og systemstabilitet, der adskiller det fra konkurrenterne. Dette positionerer RGB ikke kun som en robust platform for privatlivsfokuserede og skalerbare smarte kontrakter og tokenudstedelse, men også som en fremadskuende løsning i det bredere blockchain-rum.

Som konklusion er RGB-protokollen en betydelig teknologisk udvikling inden for Bitcoin-netværket, der tilbyder avancerede muligheder for smarte kontrakter og token-udstedelse. Den behandler nøglespørgsmål om skalerbarhed og privatliv, men står over for udfordringer med hensyn til kompleksitet og potentiel auditerbarhed. Den igangværende udvikling og fremtidige iterationer af protokollen vil sandsynligvis fokusere på at balancere disse avancerede funktioner med brugertilgængelighed og regulatoriske overvejelser.

Term referencer: 

1. Turing komplet: Rent praktisk kan systemet udføre ethvert beregningsproblem med tilstrækkelig tid og hukommelse. De fleste moderne programmeringssprog er Turing-komplet, hvilket indikerer deres teoretiske kapacitet til at løse ethvert beregningsproblem.
   
2. Skema: Et kontraktskema fungerer som den faktiske kode for en smart kontrakt, som kan bruges som en "kontraktskabelon" af udstederne uden at det er nødvendigt at kode eller revidere tilpasset kode leveret af eksterne kilder. RGB-skema er ikke et script, men er en datastruktur.
   
3. Diskrete Log-kontrakter (DLC'er) i forbindelse med statskanaler er specialiserede smarte kontrakter, der primært bruges i Bitcoin-netværket. De muliggør privat og effektiv eksekvering af komplekse finansielle aftaler baseret på eksterne begivenheder, såsom aktivpriser. DLC'er opererer uden for kæden og opretholder fortroligheden af ​​kontraktoplysninger og deltageridentiteter. De bruger eksterne datakilder eller orakler til kontraktløsning. Når de integreres med statskanaler, forbedrer DLC'er skalerbarheden ved at tillade flere transaktionsafviklinger uden at overbelaste blockchainen, hvilket gør dem ideelle til private, effektive finansielle transaktioner, der afhænger af virkelige resultater.
   
4. Storm – escrow-baseret trustless storage ved hjælp af zk-proofs. Storm kombinerer escrow-baseret, tillidsfri opbevaring med nul-viden beviser for at lette sikre og private transaktioner. I dette system opbevares data eller aktiver i depot og frigives kun, når specifikke betingelser er opfyldt, hvilket sikrer et tillidsløst miljø, hvor der ikke er behov for en central myndighed. Integrationen af ​​zk-proofs giver mulighed for verifikation af disse transaktioner, samtidig med at den opretholder den største fortrolighed, da de muliggør validering af data uden at afsløre nogen underliggende detaljer.
   
5. Prometheus – voldgiftsbaseret, tillidsløs distribueret databehandling. Prometheus repræsenterer en tilgang til decentraliseret databehandling, der kombinerer voldgiftsmekanismer til tvistbilæggelse, tillidsløse interaktioner for sikre og decentraliserede operationer og effektiviteten af ​​statskanaler til off-chain databehandling.
   
6. A Reduceret instruktionssæt computer er en type mikroprocessorarkitektur, der anvender et lille, stærkt optimeret sæt instruktioner i stedet for det højt specialiserede sæt instruktioner, der typisk findes i andre arkitekturer.