RGB Magic: Kontrakter på klientsiden på Bitcoin

Dette er en meningsredaksjon av Federico Tenga, en langvarig bidragsyter til Bitcoin-prosjekter med erfaring som gründer, konsulent og pedagog.

Begrepet "smarte kontrakter" går før oppfinnelsen av blokkjeden og selve Bitcoin. Dens første omtale er i en 1994-artikkel av Nick Szabo, som definerte smarte kontrakter som en "datastyrt transaksjonsprotokoll som utfører vilkårene i en kontrakt." Mens ved denne definisjonen Bitcoin, takket være skriptspråket, støttet smarte kontrakter fra den aller første blokken, ble begrepet populært først senere av Ethereum-promotører, som vridd den opprinnelige definisjonen som "kode som er redundant utført av alle noder i en global konsensus Nettverk"

Mens delegering av kodeutførelse til et globalt konsensusnettverk har fordeler (f.eks. er det enkelt å distribuere uskyldige kontrakter, for eksempel de populært automatiserte markedsskaperne), har denne utformingen en stor feil: mangel på skalerbarhet (og personvern). Hvis hver node i et nettverk redundant må kjøre den samme koden, forblir mengden kode som faktisk kan utføres uten å øke kostnadene ved å kjøre en node (og dermed bevare desentraliseringen) for lite, noe som betyr at bare et lite antall kontrakter kan utføres. henrettet.

Men hva om vi kunne designe et system der vilkårene i kontrakten utføres og valideres kun av de involverte partene, i stedet for av alle medlemmer av nettverket? La oss forestille oss eksemplet med et selskap som ønsker å utstede aksjer. I stedet for å publisere utstedelseskontrakten offentlig på en global hovedbok og bruke den til å spore alle fremtidige overføringer av eierskap, kan den ganske enkelt utstede aksjene privat og gi kjøperne retten til å overføre dem videre. Deretter kan retten til å overføre eierskap overføres til hver ny eier som om det var en endring av den opprinnelige utstedelseskontrakten. På denne måten kan hver eier uavhengig verifisere at aksjene han eller hun mottok er ekte ved å lese den opprinnelige kontrakten og validere at all historikk med endringer som flyttet aksjene samsvarer med reglene i den opprinnelige kontrakten.

Dette er faktisk ikke noe nytt, det er faktisk den samme mekanismen som ble brukt til å overføre eiendom før offentlige registre ble populære. I Storbritannia, for eksempel var det ikke obligatorisk å registrere en eiendom da eiendomsretten ble overført før på 90-tallet. Dette betyr at fortsatt i dag er over 15 % av landet i England og Wales uregistrert. Hvis du kjøper en uregistrert eiendom, i stedet for å sjekke i et register om selgeren er den sanne eieren, må du bekrefte en ubrutt eierkjede som går tilbake minst 15 år (en periode som anses som lang nok til å anta at selgeren har tilstrekkelig eiendomsrett til eiendommen). Ved å gjøre dette må du sørge for at eventuell eiendomsoverdragelse er korrekt gjennomført og at eventuelle pantelån som er brukt til tidligere transaksjoner er nedbetalt i sin helhet. Denne modellen har fordelen av forbedret personvern fremfor eierskap, og du trenger ikke stole på vedlikeholderen av den offentlige grunnboken. På den annen side gjør det verifiseringen av selgers eierskap mye mer komplisert for kjøperen.

Hvordan kan overdragelse av uregistrerte eiendommer forbedres? Først og fremst ved å gjøre det til en digitalisert prosess. Hvis det er kode som kan kjøres av en datamaskin for å bekrefte at all historikk for eierskapsoverføringer er i samsvar med de opprinnelige kontraktsreglene, blir kjøp og salg mye raskere og billigere.

For det andre, for å unngå risikoen for at selgeren dobbeltbruker eiendelen sin, må et system med bevis for publisering implementeres. For eksempel kan vi implementere en regel om at enhver overføring av eierskap må foretas på et forhåndsdefinert sted i en kjent avis (f.eks. legg hashen av overføringen av eierskap i øvre høyre hjørne av den første siden av New York Tider). Siden du ikke kan plassere hashen til en overføring på samme sted to ganger, forhindrer dette dobbeltbruksforsøk. Men å bruke en kjent avis til dette formålet har noen ulemper:

1. Du må kjøpe mange aviser for bekreftelsesprosessen. Ikke særlig praktisk.
2. Hver kontrakt trenger sin egen plass i avisen. Ikke veldig skalerbar.
3. Avisredaktøren kan enkelt sensurere eller, enda verre, simulere dobbeltforbruk ved å sette en tilfeldig hash i sporet ditt, få enhver potensiell kjøper av eiendelen din til å tro at den har blitt solgt før, og fraråde dem å kjøpe den. Ikke veldig tillitsløst.

Av disse grunner må det finnes et bedre sted å legge ut bevis på eierskapsoverføringer. Og hvilket bedre alternativ enn Bitcoin-blokkjeden, en allerede etablert, pålitelig offentlig hovedbok med sterke insentiver for å holde den sensurbestandig og desentralisert?

Hvis vi bruker Bitcoin, bør vi ikke spesifisere et fast sted i blokken hvor forpliktelsen til å overføre eierskap må skje (f.eks. i den første transaksjonen) fordi, akkurat som med redaktøren av New York Times, kunne gruvearbeideren rote med det. En bedre tilnærming er å plassere forpliktelsen i en forhåndsdefinert Bitcoin-transaksjon, nærmere bestemt i en transaksjon som stammer fra en ubrukt transaksjonsutgang (UTXO) som eierskapet til eiendelen som skal utstedes er knyttet til. Koblingen mellom en eiendel og en bitcoin UTXO kan oppstå enten i kontrakten som utsteder eiendelen eller i en påfølgende overføring av eierskap, hver gang gjør mål UTXO til kontrolløren av den overførte eiendelen. På denne måten har vi klart definert hvor forpliktelsen til å overføre eierskap skal være (dvs. i Bitcoin-transaksjonen som stammer fra en bestemt UTXO). Alle som kjører en Bitcoin-node kan uavhengig bekrefte forpliktelsene, og verken gruvearbeiderne eller noen annen enhet er i stand til å sensurere eller forstyrre aktivaoverføringen på noen måte.

Siden vi på Bitcoin blockchain kun publiserer en forpliktelse om en eierskapsoverføring, ikke innholdet i selve overføringen, trenger selgeren en dedikert kommunikasjonskanal for å gi kjøperen alle bevisene på at eierskapsoverføringen er gyldig. Dette kan gjøres på en rekke måter, potensielt til og med ved å skrive ut prøvetrykkene og sende dem med en brevdue, som, selv om det er litt upraktisk, fortsatt ville gjøre jobben. Men det beste alternativet for å unngå sensur og personvernbrudd er å etablere en direkte peer-to-peer kryptert kommunikasjon, som sammenlignet med duene også har fordelen av å være enkel å integrere med en programvare for å verifisere bevisene mottatt fra motparten.

Denne modellen som nettopp er beskrevet for validerte kontrakter på klientsiden og eierskapsoverføringer er nøyaktig hva som er implementert med RGB-protokollen. Med RGB er det mulig å lage en kontrakt som definerer rettigheter, tildeler dem til en eller flere eksisterende bitcoin UTXO og spesifiserer hvordan deres eierskap kan overføres. Kontrakten kan opprettes med utgangspunkt i en mal, kalt et "skjema", der skaperen av kontrakten bare justerer parametrene og eierrettighetene, slik det gjøres med tradisjonelle juridiske kontrakter. For øyeblikket er det to typer skjemaer i RGB: en for utstedelse av fungible tokens (RGB20) og en andre for utstedelse av samleobjekter (RGB21), men i fremtiden kan flere skjemaer utvikles av hvem som helst på en tillatelsesfri måte uten å kreve endringer på protokollnivå.

For å bruke et mer praktisk eksempel kan en utsteder av fungible eiendeler (f.eks. selskapsaksjer, stablecoins, etc.) bruke RGB20-skjemamalen og lage en kontrakt som definerer hvor mange tokens den vil utstede, navnet på eiendelen og noen ekstra metadata tilknyttet med det. Den kan deretter definere hvilken bitcoin UTXO som har rett til å overføre eierskap til de opprettede tokenene og tildele andre rettigheter til andre UTXOer, for eksempel retten til å foreta en sekundær utstedelse eller å renominere eiendelen. Hver klient som mottar tokens opprettet av denne kontrakten, vil være i stand til å verifisere innholdet i Genesis-kontrakten og validere at enhver overføring av eierskap i historien til tokenet som mottas, har overholdt reglene som er angitt der.

Så hva kan vi gjøre med RGB i praksis i dag? Først og fremst muliggjør det utstedelse og overføring av tokeniserte eiendeler med bedre skalerbarhet og personvern sammenlignet med alle eksisterende alternativer. På personvernsiden drar RGB nytte av det faktum at alle overføringsrelaterte data holdes på klientsiden, så en blokkjedeobservatør kan ikke trekke ut noen informasjon om brukerens økonomiske aktiviteter (det er ikke engang mulig å skille mellom en bitcoin-transaksjon som inneholder en RGB-forpliktelse fra en vanlig en), dessuten deler mottakeren med avsenderen bare blindede UTXO (dvs. hashen av sammenkoblingen mellom UTXOen som hun ønsker å motta eiendelene i og et tilfeldig nummer) i stedet for UTXO selv, så det er ikke mulig for betaleren å overvåke fremtidige aktiviteter til mottakeren. For ytterligere å øke personvernet til brukere, tar RGB også i bruk den skuddsikre kryptografiske mekanismen for å skjule beløpene i historien til eiendelsoverføringer, slik at selv fremtidige eiere av eiendeler har et uklart syn på den økonomiske oppførselen til tidligere eiere.

Når det gjelder skalerbarhet, gir RGB også noen fordeler. For det første holdes mesteparten av dataene utenfor kjeden, siden blokkjeden kun brukes som et forpliktelseslag, noe som reduserer gebyrene som må betales og betyr at hver klient kun validerer overføringene den er interessert i i stedet for alle aktiviteten til et globalt nettverk. Siden en RGB-overføring fortsatt krever en Bitcoin-transaksjon, kan gebyrbesparelsen virke minimal, men når du begynner å introdusere transaksjonsbatching kan de raskt bli massive. Det er faktisk mulig å overføre alle tokens (eller mer generelt "rettighetene") knyttet til en UTXO mot et vilkårlig antall mottakere med en enkelt forpliktelse i en enkelt bitcoin-transaksjon. La oss anta at du er en tjenesteleverandør som gjør utbetalinger til flere brukere samtidig. Med RGB kan du i en enkelt Bitcoin-transaksjon foreta tusenvis av overføringer til tusenvis av brukere som ber om forskjellige typer eiendeler, noe som gjør marginalkostnaden for hver enkelt utbetaling helt ubetydelig.

En annen avgiftsbesparende mekanisme for utstedere av eiendeler med lav verdi er at i RGB krever utstedelse av en eiendel ikke å betale gebyrer. Dette skjer fordi opprettelsen av en utstedelseskontrakt ikke trenger å være forpliktet på blokkjeden. En kontrakt definerer ganske enkelt hvilken allerede eksisterende UTXO de nylig utstedte eiendelene vil bli allokert til. Så hvis du er en artist som er interessert i å lage samlesymboler, kan du utstede så mange du vil gratis og deretter bare betale bitcoin-transaksjonsgebyret når en kjøper dukker opp og ber om at tokenet skal tildeles deres UTXO.

Videre, fordi RGB er bygget på toppen av bitcoin-transaksjoner, er den også kompatibel med Lightning Network. Selv om det ennå ikke er implementert i skrivende stund, vil det være mulig å lage aktivaspesifikke Lightning-kanaler og rute betalinger gjennom dem, på samme måte som det fungerer med vanlige Lightning-transaksjoner.

konklusjonen

RGB er en banebrytende innovasjon som åpner for nye brukstilfeller ved hjelp av et helt nytt paradigme, men hvilke verktøy er tilgjengelige for å bruke det? Hvis du ønsker å eksperimentere med selve kjernen av teknologien, bør du prøve direkte RGB node. Hvis du vil bygge applikasjoner på toppen av RGB uten å måtte dykke dypt inn i kompleksiteten til protokollen, kan du bruke rgb-lib bibliotek, som gir et enkelt grensesnitt for utviklere. Hvis du bare vil prøve å utstede og overføre eiendeler, kan du spille med Iris Wallet for Android, hvis kode også er åpen kildekode på GitHub. Hvis du bare vil lære mer om RGB kan du sjekke ut denne listen over ressurser.

Dette er et gjesteinnlegg av Federico Tenga. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc eller Bitcoin Magazine.