RGB Magic: Kontrakt på klientsidan Bitcoin

By Bitcoin Magasin - 1 år sedan - Lästid: 9 minuter
Tis 22 nov 2022 10:32

RGB Magic: Kontrakt på klientsidan Bitcoin

RGB är en metod för ägarverifiering som bygger på Bitcoin som möjliggör fortsättningen av Bitcoins fastigheter.

Detta är en åsiktsledare av Federico Tenga, en lång tid bidragsgivare till Bitcoin projekt med erfarenhet som start-up grundare, konsult och utbildare.

Termen "smarta kontrakt" går före uppfinningen av blockkedjan och Bitcoin sig. Dess första omnämnande är i en Artikel från 1994 av Nick Szabo, som definierade smarta kontrakt som ett "datoriserat transaktionsprotokoll som utför villkoren i ett kontrakt." Medan enligt denna definition Bitcoin, tack vare dess skriptspråk, stödde smarta kontrakt från det allra första blocket, termen populariserades först senare av Ethereum-promotorer, som vred den ursprungliga definitionen som "kod som exekveras redundant av alla noder i ett globalt konsensusnätverk"

Även om delegering av kodexekvering till ett globalt konsensusnätverk har fördelar (t.ex. är det lätt att distribuera oskyldiga kontrakt, såsom de populära automatiserade marknadsskaparna), har denna design ett stort fel: bristen på skalbarhet (och integritet). Om varje nod i ett nätverk redundant måste köra samma kod, förblir mängden kod som faktiskt kan exekveras utan att kostnaderna för att driva en nod överdrivet ökar (och därmed bevara decentralisering), vilket innebär att endast ett litet antal kontrakt kan utföras. avrättade.

Men tänk om vi kunde utforma ett system där villkoren i kontraktet verkställs och valideras endast av de inblandade parterna, snarare än av alla medlemmar i nätverket? Låt oss föreställa oss exemplet med ett företag som vill ge ut aktier. Istället för att publicera emissionskontraktet offentligt på en global reskontra och använda den redovisningen för att spåra alla framtida överföringar av äganderätt, kan den helt enkelt utfärda aktierna privat och överlåta till köparna rätten att ytterligare överföra dem. Då kan rätten att överlåta äganderätten föras över till varje ny ägare som om det vore en ändring av det ursprungliga emissionsavtalet. På detta sätt kan varje ägare självständigt verifiera att de aktier han eller hon erhållit är äkta genom att läsa det ursprungliga avtalet och validera att all historik över ändringar som flyttade aktierna överensstämmer med reglerna i det ursprungliga avtalet.

Detta är faktiskt inget nytt, det är verkligen samma mekanism som användes för att överföra egendom innan offentliga register blev populära. I UKt.ex. var det inte obligatoriskt att registrera en fastighet när dess äganderätt överfördes förrän på 90-talet. Detta betyder att än idag är över 15 % av marken i England och Wales oregistrerad. Om du köper en oregistrerad fastighet, istället för att kontrollera i ett register om säljaren är den sanna ägaren, måste du verifiera en obruten ägandekedja som går tillbaka minst 15 år (en period som anses vara tillräckligt lång för att anta att säljaren har tillräcklig äganderätt till fastigheten). Därvid måste du försäkra dig om att eventuell äganderättsöverlåtelse har genomförts korrekt och att eventuella bolån som använts för tidigare transaktioner har betalats av i sin helhet. Denna modell har fördelen av förbättrad integritet framför ägande, och du behöver inte förlita dig på den som upprätthåller det offentliga fastighetsregistret. Å andra sidan gör det verifieringen av säljarens ägande mycket mer komplicerad för köparen.

Hur kan överlåtelsen av oregistrerade fastigheter förbättras? Först och främst genom att göra det till en digitaliserad process. Om det finns kod som kan köras av en dator för att verifiera att all historia av ägandeöverföringar är i överensstämmelse med de ursprungliga avtalsreglerna, blir köp och försäljning mycket snabbare och billigare.

För det andra, för att undvika risken för att säljaren dubbelutgifter sin tillgång, måste ett system med bevis för publicering implementeras. Till exempel skulle vi kunna implementera en regel om att varje överföring av äganderätt måste utföras på en fördefinierad plats i en välkänd tidning (t.ex. placera hashen för överföringen av äganderätt i det övre högra hörnet på första sidan av New York tider). Eftersom du inte kan placera hashen för en överföring på samma plats två gånger, förhindrar detta försök med dubbla utgifter. Att använda en berömd tidning för detta ändamål har dock några nackdelar:

Av dessa skäl måste man hitta ett bättre ställe att lägga upp bevis på ägandeöverföringar. Och vilket bättre alternativ än Bitcoin blockchain, en redan etablerad pålitlig offentlig reskontra med starka incitament att hålla den censurbeständig och decentraliserad?

Om vi ​​använder Bitcoin, vi bör inte ange en fast plats i blocket där åtagandet att överföra äganderätten måste ske (t.ex. i den första transaktionen) eftersom, precis som med redaktören för New York Times, kunde gruvarbetaren bråka med det. Ett bättre tillvägagångssätt är att placera engagemanget i ett fördefinierat Bitcoin transaktion, närmare bestämt i en transaktion som härrör från en outnyttjad transaktionsoutput (UTXO) till vilken ägandet av den tillgång som ska emitteras är kopplad. Kopplingen mellan en tillgång och en bitcoin UTXO kan förekomma antingen i kontraktet som utfärdar tillgången eller i en efterföljande överföring av äganderätt, varje gång som gör mål UTXO till kontrollant av den överförda tillgången. På detta sätt har vi tydligt definierat var skyldigheten att överföra äganderätten bör vara (dvs Bitcoin transaktion som härrör från en viss UTXO). Alla som kör en Bitcoin noden kan självständigt verifiera åtagandena och varken gruvarbetarna eller någon annan enhet kan censurera eller störa tillgångsöverföringen på något sätt.

Sedan på Bitcoin blockchain vi publicerar endast ett åtagande om en ägaröverföring, inte innehållet i själva överföringen, säljaren behöver en dedikerad kommunikationskanal för att förse köparen med alla bevis på att ägaröverföringen är giltig. Detta skulle kunna göras på ett antal sätt, potentiellt till och med genom att skriva ut korrekturen och skicka dem med en brevduva, vilket, även om det är lite opraktiskt, ändå skulle göra jobbet. Men det bästa alternativet för att undvika censuren och integritetskränkningarna är att upprätta en direkt peer-to-peer-krypterad kommunikation, som jämfört med duvorna också har fördelen av att den är lätt att integrera med en programvara för att verifiera bevisen som motparten fått.

Den här modellen som just beskrivits för validerade kontrakt och ägarskapsöverföringar på klientsidan är exakt vad som har implementerats med RGB-protokollet. Med RGB är det möjligt att skapa ett kontrakt som definierar rättigheter, tilldelar dem till en eller flera befintliga bitcoin UTXO och anger hur deras ägande kan överföras. Kontraktet kan skapas med utgångspunkt från en mall, som kallas ett "schema", där skaparen av kontraktet endast justerar parametrarna och äganderätten, som görs med traditionella juridiska kontrakt. För närvarande finns det två typer av scheman i RGB: ett för att utfärda fungible tokens (RGB20) och en andra för att ge ut samlarföremål (RGB21), men i framtiden kan fler scheman utvecklas av vem som helst på ett tillståndslöst sätt utan att kräva ändringar på protokollnivå.

För att använda ett mer praktiskt exempel kan en emittent av utbytbara tillgångar (t.ex. företagsaktier, stablecoins, etc.) använda RGB20-schemamallen och skapa ett kontrakt som definierar hur många tokens den kommer att utfärda, namnet på tillgången och ytterligare metadata kopplade till med det. Den kan sedan definiera vilken bitcoin UTXO har rätten att överföra äganderätten till de skapade tokens och tilldela andra rättigheter till andra UTXO, såsom rätten att göra en sekundär emission eller att omnominera tillgången. Varje klient som tar emot tokens som skapats av detta kontrakt kommer att kunna verifiera innehållet i Genesis-kontraktet och validera att varje överföring av äganderätt i historien för den mottagna tokenen har följt reglerna som anges där.

Så vad kan vi göra med RGB i praktiken idag? Först och främst möjliggör det utfärdande och överföring av tokeniserade tillgångar med bättre skalbarhet och integritet jämfört med alla befintliga alternativ. På integritetssidan drar RGB nytta av att all överföringsrelaterad data hålls på klientsidan, så en blockchain-observatör kan inte extrahera någon information om användarens ekonomiska aktiviteter (det är inte ens möjligt att särskilja en bitcoin transaktion som innehåller ett RGB-åtagande från ett vanligt), dessutom delar mottagaren med avsändaren endast blindad UTXO (dvs. hashen av sammanlänkningen mellan den UTXO i vilken hon vill ta emot tillgångarna och ett slumpmässigt nummer) istället för själva UTXO:n , så det är inte möjligt för betalaren att övervaka mottagarens framtida aktiviteter. För att ytterligare öka användarnas integritet, använder RGB också den skottsäkra kryptografiska mekanismen för att dölja beloppen i historien om tillgångsöverföringar, så att även framtida ägare av tillgångar har en förvirrad bild av tidigare innehavares ekonomiska beteende.

När det gäller skalbarhet erbjuder RGB också vissa fördelar. Först och främst hålls det mesta av data utanför kedjan, eftersom blockkedjan endast används som ett åtagandelager, vilket minskar avgifterna som måste betalas och innebär att varje kund endast validerar de överföringar den är intresserad av istället för alla aktivitet i ett globalt nätverk. Eftersom en RGB-överföring fortfarande kräver en Bitcoin transaktion kan avgiftsbesparingen verka minimal, men när du börjar introducera transaktionsbatchning kan de snabbt bli enorma. Det är faktiskt möjligt att överföra alla tokens (eller, mer allmänt, "rättigheter") associerade med en UTXO till ett godtyckligt antal mottagare med ett enda åtagande i en enda bitcoin transaktion. Låt oss anta att du är en tjänsteleverantör som gör utbetalningar till flera användare samtidigt. Med RGB kan du begå i en singel Bitcoin transaktion tusentals överföringar till tusentals användare som begär olika typer av tillgångar, vilket gör marginalkostnaden för varje enskild utbetalning absolut försumbar.

En annan avgiftsbesparande mekanism för emittenter av lågvärdestillgångar är att i RGB kräver emissionen av en tillgång inga avgifter. Detta händer eftersom skapandet av ett emissionskontrakt inte behöver bindas på blockkedjan. Ett kontrakt definierar helt enkelt till vilken redan befintlig UTXO de nyligen utgivna tillgångarna kommer att allokeras till. Så om du är en artist som är intresserad av att skapa samlarpoletter kan du ge ut så många du vill gratis och sedan bara betala bitcoin transaktionsavgift när en köpare dyker upp och begär att token ska tilldelas deras UTXO.

Dessutom eftersom RGB är byggt ovanpå bitcoin transaktioner, är den också kompatibel med Lightning Network. Även om det ännu inte är implementerat i skrivande stund kommer det att vara möjligt att skapa tillgångsspecifika Lightning-kanaler och dirigera betalningar genom dem, liknande hur det fungerar med vanliga Lightning-transaktioner.

Slutsats

RGB är en banbrytande innovation som öppnar upp för nya användningsfall med hjälp av ett helt nytt paradigm, men vilka verktyg finns tillgängliga för att använda det? Om du vill experimentera med själva kärnan av tekniken bör du direkt prova RGB-nod. Om du vill bygga applikationer ovanpå RGB utan att behöva djupdyka i protokollets komplexitet kan du använda rgb-lib bibliotek, som ger ett enkelt gränssnitt för utvecklare. Om du bara vill försöka ge ut och överföra tillgångar kan du spela med Iris Wallet för Android, vars kod också är öppen källkod på GitHub. Om du bara vill lära dig mer om RGB kan du kolla in denna lista med resurser.

Detta är ett gästinlägg av Federico Tenga. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis de från BTC Inc Bitcoin Tidskrift.

Ursprunglig källa: Bitcoin magazine