En kort introduktion til RGB-protokoller

Den 3. januar 2009 lancerede Satoshi Nakamoto den første Bitcoin-node. Fra det øjeblik kom nye noder til, og Bitcoin begyndte at opføre sig, som om det var en ny livsform, en livsform, der ikke er holdt op med at udvikle sig. Lidt efter lidt er det blevet det sikreste netværk i verden som et resultat af dets unikke design - meget gennemtænkt af Satoshi - fordi det gennem økonomiske incitamenter tiltrækker brugere, almindeligvis kaldet minearbejdere, til at investere i energi og computerkraft, som bidrager til netværkssikkerhed.

Da Bitcoin fortsætter sin vækst og adoption, står den over for skalerbarhedsproblemer. Bitcoin-netværket tillader en ny blok med transaktioner, der kan udvindes på cirka 10 minutter. Hvis vi antager, at vi har 144 blokke på en dag med maksimale værdier på 2,700 transaktioner pr. blok, ville Bitcoin kun have tilladt 4.5 transaktioner i sekundet. Satoshi var klar over denne begrænsning, vi kan se det i en e-mail sendt til Mike Hearn i marts 2011, hvor han forklarer, hvordan det, vi kender i dag som betalingskanal, fungerer. Det er her off-chain protokoller kommer ind.

Ifølge Christian Decker, off-chain protokoller er normalt systemer, hvor brugere bruger data fra en blockchain og administrerer den uden at røre selve blockchain indtil sidste øjeblik. Baseret på dette koncept blev Lightning Network født, et netværk, der bruger off-chain-protokoller til at tillade Bitcoin-betalinger næsten øjeblikkeligt. Da ikke alle disse operationer er skrevet på blockchain, tillader den tusindvis af transaktioner i sekundet og skalerer Bitcoin.

Forskning og udvikling inden for off-chain protokoller på Bitcoin har åbnet en Pandoras æske. I dag ved vi, at vi kan opnå meget mere end værdioverførsel på en decentral måde, nonprofit LNP/BP Standards Association fokuserer på udvikling af Layer 2 og 3 protokoller på Bitcoin og Lightning Network. Blandt disse projekter, RGB skiller sig ud.

Hvad er RGB?

RGB var baseret på forskning af Peter Todd om engangsforseglinger og validering på klientsiden og tænkt i 2016 af Giacomo Zucco som en bedre aktivprotokol for Bitcoin og Lightning Network. Yderligere udvikling af disse ideer førte til udviklingen af ​​RGB til et fuldt udbygget smart kontraktsystem af Maxim Orlovsky, som har ledet implementeringen af ​​det siden 2019 med deltagelse i samfundet.

Vi kan definere RGB som et sæt af open source-protokoller, der giver os mulighed for at udføre komplekse smarte kontrakter på en skalerbar og fortrolig måde. Det er ikke et bestemt netværk (som Bitcoin eller Lightning); hver smart kontrakt er blot et sæt kontraktdeltagere, som kan interagere ved hjælp af forskellige kommunikationskanaler (som standard til Lightning Network). RGB bruger Bitcoin blockchain som et lag af statsforpligtelse og vedligeholder koden for den smarte kontrakt og dataene uden for kæden, hvilket gør den skalerbar. Ved at udnytte Bitcoin-transaktioner (og Script) som et ejerskabskontrolsystem for smarte kontrakter, er udviklingen af ​​den smarte kontrakt defineret af en off-chain-ordning. Det er vigtigt at bemærke, at alt er valideret på klientsiden.

Enkelt sagt er RGB et system, der giver brugeren mulighed for at auditere en smart kontrakt, udføre den og verificere den individuelt til enhver tid uden ekstra omkostninger, da den ikke bruger en blockchain, som "traditionelle" systemer gør. Mens komplekse smarte kontraktsystemer blev banebrydende af Ethereum, kræver det, at brugeren bruger betydelige mængder gas for hver operation, og den opnåede aldrig den skalerbarhed, den lovede. Som følge heraf var Ethereum aldrig en mulighed for at banke de brugere udelukket fra det nuværende finansielle system.

I øjeblikket fremmer blockchain-industrien, at både koden for smarte kontrakter og data skal lagres i blockchain og udføres af hver enkelt knude på netværket, uanset den overdrevne stigning i størrelse eller misbrug af beregningsressourcer. Ordningen foreslået af RGB er meget mere intelligent og effektiv, da den skærer med dette blockchain-paradigme ved at have smarte kontrakter og data adskilt fra blockchain og dermed undgår mætning af netværket set i andre platforme. Til gengæld tvinger RGB ikke hver node til at udføre hver kontrakt, men snarere de involverede parter, hvilket tilføjer fortrolighed til et niveau, der aldrig er set før.

Smarte kontrakter i RGB

I RGB definerer en smart kontraktudvikler et skema, der specificerer regler for, hvordan kontrakten udvikler sig over tid. Skemaet er standarden for konstruktion af smarte kontrakter i RGB: Både en udsteder, når de definerer en kontrakt, og en tegnebog eller børs skal overholde en bestemt ordning, som de skal validere kontrakten imod. Kun hvis valideringen er korrekt, kan hver part acceptere anmodninger og arbejde med aktivet.

En smart kontrakt i RGB er en rettet acyklisk graf (DAG) af tilstandsændringer, hvor kun en del af grafen altid er kendt, og der ikke er adgang til resten. RGB-skemaet er et kernesæt af regler for udviklingen af ​​denne graf, som den smarte kontrakt starter med. Hver kontraktdeltager kan tilføje disse regler (hvis dette er tilladt af skemaet), og den resulterende graf er bygget ud fra den iterative anvendelse af disse regler.

Fungible aktiver

De fungible aktiver i RGB følger LNP/BP RGB-20 specifikation. Så når en RGB-20 er defineret, distribueres aktivdataene kendt som "genesis data" gennem Lightning Network, som indeholder det, der kræves for at bruge aktivet. Den mest basale form for aktiver tillader ikke sekundær udstedelse, token-brænding, renominering eller udskiftning.

Nogle gange bliver udstederen nødt til at udstede flere tokens i fremtiden, såsom stablecoins såsom USDT, som holder værdien af ​​hvert token bundet til værdien af ​​en inflationær valuta såsom USD. For at opnå dette findes der mere komplekse RGB-20-skemaer, og ud over genesedataene kræver de, at udstederen producerer forsendelser, som også vil cirkulere i Lightning Network. Med disse oplysninger kan vi kende den samlede cirkulerende forsyning af aktivet. Det samme gælder for afbrænding af aktiver eller ændring af navn.

Oplysningerne relateret til aktivet kan være offentlige eller private: Hvis udstederen kræver fortrolighed, kan de vælge ikke at dele oplysninger om tokenet og udføre operationer i absolut fortrolighed, men vi har også det modsatte tilfælde, hvor udstederen og indehaverne har brug for hele processen skal være gennemsigtig. Dette opnås ved at dele token-dataene.

RGB-20-procedurer

Brændingsproceduren deaktiverer tokens, og brændte tokens kan ikke bruges længere. Udskiftningsproceduren sker, når tokens brændes, og en ny mængde af det samme token oprettes. Dette hjælper med at reducere størrelsen af ​​aktivets historiske data, hvilket er vigtigt for at opretholde aktivets hastighed. For at understøtte use casen, hvor det er muligt at brænde aktiver uden at skulle erstatte dem, bruges et underskema af RGB-20, der kun tillader brænding af aktiver.

Non-Fungible Tokens

De ikke-fungible tokens (NFT'er) i RGB følger LNP/BP RGB-21 specifikation, når vi arbejder med NFT'er har vi også et hovedskema og et underskema. Disse skemaer har en graveringsprocedure, som giver os mulighed for at vedhæfte brugerdefinerede data af token-ejeren. Det mest almindelige eksempel, vi ser i NFT'er i dag, er digital kunst knyttet til tokenet. Tokenudstederen kan forbyde denne datagravering ved at bruge RGB-21-underskemaet. I modsætning til andre NFT blockchain-systemer tillader RGB distribution af store medietokendata på en fuldstændig decentraliseret og censurresistent måde ved at bruge en udvidelse til Lightning P2P Network kaldet Bifrost, som også bruges til at bygge mange andre former for RGB- specifikke smarte kontraktfunktioner.

Ud over fungible aktiver og NFT'er kan RGB og Bifrost bruges til at producere andre former for smarte kontrakter, herunder decentraliserede børser (DEX'er), likviditetspuljer, algoritmiske stabile mønter og mere, som vi vil dække i fremtidige artikler.

NFT fra RGB versus NFT fra andre platforme

• Intet behov for dyr blockchain-opbevaring.
• Intet behov for InterPlanetary File System (IPFS), en Lightning Network-udvidelse (kaldet Bifrost) bruges i stedet (og den er fuldstændigt ende-til-ende-krypteret).
• Intet behov for en speciel datahåndteringsløsning (igen, Bifrost tager den rolle).
• Ingen grund til at stole på, at websteder vedligeholder data for NFT-tokens eller om udsteders aktiver eller kontrakt-ABI'er.
• RGB har indbygget DRM-kryptering og ejerskabsstyring.
• RGB har infrastruktur til sikkerhedskopiering ved hjælp af Lightning Network (Bifrost).
• RGB har måder at tjene penge på indhold (ikke kun at sælge selve NFT, men adgang til indholdet flere gange).

konklusioner

Siden lanceringen af ​​Bitcoin for næsten 13 år siden, har der været meget forskning og eksperimentering på området. Både succeserne og fejlene har givet os mulighed for at forstå lidt mere, hvordan decentrale systemer opfører sig i praksis, hvad der gør dem reelt decentraliserede, og hvilke handlinger der har tendens til at føre dem til centralisering. Alt dette har fået os til at konkludere, at reel decentralisering er et sjældent og vanskeligt fænomen at opnå; reel decentralisering er kun opnået med Bitcoin, og det er af denne grund, at vi fokuserer vores bestræbelser på at bygge ovenpå.

RGB har sit eget kaninhul i Bitcoin-kaninhullet. Mens jeg falder ned gennem dem begge, vil jeg poste, hvad jeg har lært. I den næste artikel vil vi have en introduktion til LNP- og RGB-knuderne, og hvordan man bruger dem.

Dette er et gæsteindlæg af Francisco Calderón. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC, Inc. eller Bitcoin Magazine.

Kilde: https://bitcoinmagazine.com/guides/a-brief-introduction-to-rgb-protocols