En kort introduksjon til RGB-protokoller

3. januar 2009 lanserte Satoshi Nakamoto den første Bitcoin-noden. Fra det øyeblikket kom nye noder og Bitcoin begynte å oppføre seg som om det var en ny livsform, en livsform som ikke har sluttet å utvikle seg. Litt etter litt har det blitt det sikreste nettverket i verden som et resultat av dets unike design – veldig gjennomtenkt av Satoshi – fordi det, gjennom økonomiske insentiver, tiltrekker brukere, ofte kalt gruvearbeidere, til å investere i energi og datakraft som bidrar til nettverkssikkerhet.

Når Bitcoin fortsetter sin vekst og adopsjon, står den overfor skalerbarhetsproblemer. Bitcoin-nettverket lar en ny blokk med transaksjoner utvinnes på omtrent 10 minutter. Forutsatt at vi har 144 blokker på en dag med maksimale verdier på 2,700 transaksjoner per blokk, ville Bitcoin bare ha tillatt 4.5 transaksjoner per sekund. Satoshi var klar over denne begrensningen, vi kan se den i en emalje sendt til Mike Hearn i mars 2011 hvor han forklarer hvordan det vi i dag kjenner som betalingskanal fungerer. Det er her off-chain-protokoller kommer inn.

Ifølge Christian Decker, off-chain-protokoller er vanligvis systemer der brukere bruker data fra en blokkjede og administrerer den uten å berøre selve blokkjeden før i siste liten. Basert på dette konseptet ble Lightning Network født, et nettverk som bruker protokoller utenfor kjeden for å tillate at Bitcoin-betalinger utføres nesten umiddelbart. Siden ikke alle disse operasjonene er skrevet på blokkjeden, tillater den tusenvis av transaksjoner per sekund og skalerer Bitcoin.

Forskning og utvikling innen området off-chain-protokoller på Bitcoin har åpnet en Pandoras boks. I dag vet vi at vi kan oppnå mye mer enn verdioverføring på en desentralisert måte, den ideelle organisasjonen LNP/BP Standards Association fokuserer på utvikling av lag 2 og 3 protokoller på Bitcoin og Lightning Network. Blant disse prosjektene, RGB skiller seg ut.

Hva er RGB?

RGB var basert på forskning av Peter Todd på engangsforseglinger og validering på klientsiden og ble i 2016 sett for seg av Giacomo Zucco som en bedre aktivaprotokoll for Bitcoin og Lightning Network. Videre utvikling av disse ideene førte til utviklingen av RGB til et fullverdig smart kontraktssystem av Maxim Orlovsky, som har ledet implementeringen siden 2019 med samfunnsdeltakelse.

Vi kan definere RGB som et sett med åpen kildekode-protokoller som lar oss utføre komplekse smarte kontrakter på en skalerbar og konfidensiell måte. Det er ikke et bestemt nettverk (som Bitcoin eller Lightning); hver smart kontrakt er bare et sett med kontraktsdeltakere som kan samhandle ved hjelp av forskjellige kommunikasjonskanaler (som standard til Lightning Network). RGB bruker Bitcoin blockchain som et lag av statlig forpliktelse og opprettholder koden til den smarte kontrakten og dataene utenfor kjeden, noe som gjør den skalerbar. Ved å utnytte Bitcoin-transaksjoner (og Script) som et eierskapskontrollsystem for smarte kontrakter, er utviklingen av den smarte kontrakten definert av en off-chain-ordning. Det er viktig å merke seg at alt er validert på klientsiden.

Enkelt sagt er RGB et system som lar brukeren revidere en smart kontrakt, utføre den og verifisere den individuelt når som helst uten ekstra kostnad siden den ikke bruker en blokkjede som "tradisjonelle" systemer gjør. Mens komplekse smarte kontraktsystemer ble utviklet av Ethereum, krever det at brukeren bruker betydelige mengder gass for hver operasjon, og den oppnådde aldri skalerbarheten den lovet. Som en konsekvens var Ethereum aldri et alternativ for å banke brukere ekskludert fra det nåværende finansielle systemet.

For tiden fremmer blokkjedeindustrien at både koden for smarte kontrakter og dataene må lagres i blokkjeden og utføres av hver node i nettverket, uavhengig av den overdrevne økningen i størrelse eller misbruk av beregningsressurser. Ordningen foreslått av RGB er mye mer intelligent og effektiv siden den skjærer med dette blokkjedeparadigmet ved å ha smarte kontrakter og data atskilt fra blokkjeden og dermed unngår metningen av nettverket sett på andre plattformer. På sin side tvinger ikke RGB hver node til å utføre hver kontrakt, men heller partene som er involvert, noe som gir konfidensialitet til et nivå som aldri har vært sett før.

Smarte kontrakter i RGB

I RGB definerer en smart kontraktsutvikler et skjema som spesifiserer regler for hvordan kontrakten utvikler seg over tid. Skjemaet er standarden for konstruksjon av smarte kontrakter i RGB: Både en utsteder når de definerer en kontrakt og en lommebok eller børs må følge en bestemt ordning som de må validere kontrakten mot. Bare hvis valideringen er korrekt kan hver part godta forespørsler og arbeide med eiendelen.

En smart kontrakt i RGB er en rettet asyklisk graf (DAG) av tilstandsendringer, der bare en del av grafen alltid er kjent og det ikke er tilgang til resten. RGB-ordningen er et kjernesett med regler for utviklingen av denne grafen som den smarte kontrakten starter med. Hver kontraktsdeltaker kan legge til disse reglene (hvis dette tillates av skjemaet) og den resulterende grafen er bygget fra den iterative bruken av disse reglene.

Fungible eiendeler

De fungible eiendelene i RGB følger LNP/BP RGB-20-spesifikasjon. Så når en RGB-20 er definert, distribueres aktivadataene kjent som "genesis data" gjennom Lightning Network, som inneholder det som kreves for å bruke aktivaet. Den mest grunnleggende formen for eiendeler tillater ikke sekundær utstedelse, tokenbrenning, renominering eller erstatning.

Noen ganger vil utstederen trenge å utstede flere tokens i fremtiden, for eksempel stablecoins som USDT, som holder verdien av hvert token knyttet til verdien av en inflasjonsvaluta som USD. For å oppnå dette finnes det mer komplekse RGB-20-skjemaer, og i tillegg til genesis-dataene krever de at utstederen produserer forsendelser, som også vil sirkulere i Lightning Network. Med denne informasjonen kan vi vite den totale sirkulerende forsyningen av eiendelen. Det samme gjelder for brenning av eiendeler eller endring av navn.

Informasjonen knyttet til eiendelen kan være offentlig eller privat: Hvis utsteder krever konfidensialitet, kan de velge å ikke dele informasjon om token og utføre operasjoner i absolutt privatliv, men vi har også det motsatte tilfellet der utstederen og innehaverne trenger hele prosessen skal være gjennomsiktig. Dette oppnås ved å dele token-dataene.

RGB-20-prosedyrer

Brenneprosedyren deaktiverer tokens og brente tokens kan ikke brukes lenger. Erstatningsprosedyren skjer når tokens brennes og en ny mengde av samme token opprettes. Dette bidrar til å redusere størrelsen på aktivaens historiske data, noe som er viktig for å opprettholde aktivahastigheten. For å støtte brukssaken der det er mulig å brenne eiendeler uten å måtte erstatte dem, brukes et underskjema av RGB-20 som kun tillater brenning av eiendeler.

Ikke-svimmelbare symboler

De ikke-fungible tokens (NFT) i RGB følger LNP/BP RGB-21-spesifikasjon, når vi jobber med NFT-er har vi også et hovedskjema og et underskjema. Disse skjemaene har en graveringsprosedyre, som lar oss legge ved egendefinerte data av token-eieren. Det vanligste eksemplet vi ser i NFT-er i dag er digital kunst knyttet til token. Tokenutstederen kan forby denne datagraveringen ved å bruke RGB-21-underskjemaet. I motsetning til andre NFT-blokkjedesystemer, tillater RGB distribusjon av medietokendata i stor størrelse på en fullstendig desentralisert og sensurbestandig måte, ved å bruke en utvidelse til Lightning P2P Network kalt Bifrost, som også brukes til å bygge mange andre former for RGB- spesifikke smarte kontraktsfunksjoner.

I tillegg til fungible eiendeler og NFT-er, kan RGB og Bifrost brukes til å produsere andre former for smarte kontrakter, inkludert desentraliserte børser (DEX), likviditetspooler, algoritmiske stabile mynter og mer, som vi vil dekke i fremtidige artikler.

NFT fra RGB versus NFT fra andre plattformer

• Ikke behov for dyr blokkjedelagring.
• Ingen behov for InterPlanetary File System (IPFS), en Lightning Network-utvidelse (kalt Bifrost) brukes i stedet (og den er fullstendig ende-til-ende-kryptert).
• Ikke behov for en spesiell datahåndteringsløsning (igjen, Bifrost tar den rollen).
• Du trenger ikke å stole på nettsteder for å vedlikeholde data for NFT-tokens eller om utsteders eiendeler eller kontrakts-ABI.
• RGB har innebygd DRM-kryptering og eierskapsstyring.
• RGB har infrastruktur for sikkerhetskopiering ved hjelp av Lightning Network (Bifrost).
• RGB har måter å tjene penger på innhold (ikke bare selge selve NFT, men tilgang til innholdet flere ganger).

Konklusjoner

Siden lanseringen av Bitcoin, for nesten 13 år siden, har det vært mye forskning og eksperimentering på området. Både suksessene og feilene har gjort det mulig for oss å forstå litt mer hvordan desentraliserte systemer oppfører seg i praksis, hva som gjør dem virkelig desentraliserte og hvilke handlinger som har en tendens til å føre dem til sentralisering. Alt dette har ført til at vi har konkludert med at reell desentralisering er et sjeldent og vanskelig fenomen å oppnå; reell desentralisering har bare blitt oppnådd med Bitcoin, og det er av denne grunn at vi fokuserer vår innsats for å bygge på toppen av det.

RGB har sitt eget kaninhull i Bitcoin-kaninhullet. Mens jeg faller ned gjennom dem begge, vil jeg legge ut det jeg har lært. I neste artikkel vil vi ha en introduksjon til LNP- og RGB-nodene og hvordan du bruker dem.

Dette er et gjesteinnlegg av Francisco Calderón. Uttrykte meninger er helt deres egne og gjenspeiler ikke nødvendigvis de til BTC, Inc. eller Bitcoin Magazine.

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