RGB stärker Bitcoin och Lightning Networks skalbarhet och sekretessfunktioner

TL; DR

• RGB fungerar som en Layer 2/3-lösning på valideringsparadigmet för Bitcoin och Lightning Network.klientsidan, som innehåller alla smarta kontraktsdata utanför Bitcoin-transaktioner. Denna design säkerställer att systemet fungerar ovanpå Lightning Network, vilket eliminerar behovet av modifieringar av LN-protokoll.
  
• RGB smarta kontrakt är designade för skalbarhet och konfidentialitet. Systemet stöder privat och ömsesidigt ägande, abstraherar och separerar problem, vilket representerar en Turing-komplett form av förtroendelös distribuerad datoranvändning efter blockchain utan att behöva introducera nya tokens.
  
• RGB-kontrakt är organiserade i separata segment som kallas "skärvor", var och en med sin egen historia och data, vilket förbättrar skalbarheten och förhindrar blandning av historier från olika kontrakt. De interagerar via Bifrost-protokollet på Lightning Network, vilket möjliggör samordnade förändringar mellan flera parter, liknande DEX:er som arbetar på Lightning Network.
  
• RGB använder sig av engångstätningar defined över Bitcoin UTXO för säkerhet. Varje part som har en smart kontraktstillståndshistoria kan verifiera dess unikhet genom att utnyttja Bitcoins skript till define ägande och åtkomsträtt.
  
• I RGB är statligt ägande och validering separata enheter. Äganderätten hanteras av Bitcoin-skriptet, ett icke-Turing Complete-system. Valideringsregler, å andra sidan, dikteras av RGB-schemat med hjälp av Turing Complete Simplicity/Contractum/Rust Script.
  
• Varje smart RGB-kontrakt är associerat med ett unikt tillstånd med engångsförseglingar. Sigillen och staten följer specifika regler och valideringar som fastställts av kontraktets skapare, styrda av ett "schema". Detta schema fungerar som en regeluppsättning för att kontrollera kontraktsdata på klientsidan, vilket möjliggör en hög nivå av protokollskalbarhet och integritet.
  
• RGB:s design är mycket interoperabel med befintliga Bitcoin- och Lightning Network-tekniker, vilket underlättar sömlös integration med dessa plattformar och eventuella framtida uppgraderingar.
  
• Till skillnad från den imperativa programmeringsstilen för många blockchain-plattformar, använder RGB en deklarativ stil. Detta tillvägagångssätt fokuserar på att beskriva det önskade resultatet snarare än att specificera de specifika stegen för att uppnå det.
  
• RGB använder olika avancerade teknologier, inklusive AluVM för deterministiska bärbara datoruppgifter, PRISM för delvis replikerade infinite state-maskiner och Storm för depositionsbaserad trustless lagring med zk-proofs. Dessa teknologier bidrar till RGB:s robusthet, konfidentialitet och utbyggbarhet.
  
• RGB (v0.10) introducerar anmärkningsvärda förbättringar av användarupplevelsen och integrationsprocesser, effektiviserar verksamheten och minimerar beroenden. Den uppdaterade versionen har ett mer enhetligt biblioteks-API och kommandoradsverktyg, vilket gör det mer tillgängligt och användarvänligt.

Kort beskrivning

RGB är ett protokoll designat för att utfärda tokens på Bitcoin-nätverket med förbättrad integritet och kompatibilitet med Lightning Network. Det bygger på konceptet med "färgade mynt", som de som används i OmniLayer-protokollet där metadata i Bitcoin-transaktioner indikerar en tokenöverföring. Till exempel fungerar USDT-transaktioner på OmniLayer som Bitcoin-transaktioner utökade med ytterligare data som beskriver USDT-tokens rörelser. Dessa metoder möter dock begränsningar såsom datastorleksbegränsningar i OP_RETURN-utgångar, intensiv blockchain-skanning och begränsad integritet som härrör från synlighet i kedjan.

RGB åtgärdar dessa problem genom att flytta majoriteten av valideringsprocesserna bort från Bitcoin-blockkedjan. Den antar validering på klientsidan och använder sigill för engångsbruk för att ansluta tokens med Bitcoins UTXO, samtidigt som användarnas integritet bevaras.

Tokens överförs genom att förbinda sig till ett meddelande som innehåller RGB-betalningsinformation inom en Bitcoin-transaktion, vilket gör att tokens kan flyttas från en UTXO till en annan utan att lämna ett spår på Bitcoin-transaktionsgrafen. Detta förbättrar integriteten avsevärt, eftersom RGB-transaktioner "teleporterar" tokens diskret, med RGB-specifik data som skickas via privata kanaler utanför kedjan.

Dessutom, för att säkerställa ägande och förhindra inflation, måste mottagare validera hela transaktionshistoriken för de mottagna tokens. RGB möjliggör framtida uppgraderingar utan behov av hårda gafflar, vilket säkerställer att gruvarbetare inte kan spåra tillgångsflöden, vilket ger ett högre motstånd mot censur. Till skillnad från traditionella blockchain-strukturer, fungerar RGB utan behov av block eller kedjor, positionerar det som ett icke-block decentraliserat protokoll, som lovar hög konfidentialitet, säkerhet och skalbarhet.

Introduktion och vision

Oneliner: Ett klientvaliderat tillstånd och smarta kontraktssystem som fungerar på Layer 2/3 i Bitcoin och Lightning Network.

Mer information:

RGB är ett skalbart och konfidentiellt smart kontraktssystem för Bitcoin & Lightning Network. RGB smarta kontrakt fungerar med validering på klientsidan paradigm, bostad alla smarta kontraktsdata utanför Bitcoin-transaktioner, det vill säga Bitcoin blockchain eller Lightning-kanaltillstånd. Detta gör att systemet kan arbeta ovanpå Lightning Network utan några ändringar av LN-protokollen och ger också en grund för en hög nivå av protokollskalbarhet och integritet.

Smarta kontrakt förkroppsligar principer om privat och ömsesidigt ägande, abstraktion och åtskillnad av intressen. De representerar en "post-blockchain", Turing-komplett form av tillförlitlig distribuerad datoranvändning som inte kräver introduktion av tokens.

RGB-kontrakt fungerar i separata segment som kallas "skärvor". Varje skärva har sin egen historia och data, vilket innebär att olika kontrakt inte blandar sin historia. Denna metod förbättrar skalbarheten. Termen "shard" används för att visa att RGB uppnår liknande mål som det som var tänkt med Ethereums shards-koncept.

Även om de fungerar oberoende, kan RGB-kontrakt interagera genom Bifrost-protokollet på Lightning Network. Detta möjliggör samordnade förändringar mellan flera parter. Det gör till exempel att DEX:er kan fungera över Lightning Network.

Teknik & Arkitektur

Översikt över RGB-drift och engångstätningar på hög nivå

Figur 1. Översikt över driften av RGB på hög nivå.
Källa: LNP/BP Association Github.

Som en säkerhetsmekanism använder RGB tätningar för engångsbruk defined över bitcoin UTXO, som ger möjlighet för alla parter som har smart kontraktstillståndshistorik att verifiera dess unika karaktär. I huvudsak använder RGB Bitcoin-skript för sin säkerhetsmodell och defines ägande och åtkomsträttigheter.

Figur 2. RGB Arbetsprincip på hög nivå.
Källa: "Driving Mass Adoption of Crypto: How the RGB Protocol is Illuminating the Future of Bitcoin" av Waterdrip Capital.

Varje RGB smart kontrakt är defined av a genesis tillstånd, tillverkad av smart kontraktsutfärdare (eller, enkelt uttryckt, utfärdare) och en riktad acyklisk graf (DAG) av statliga övergångar bevaras som klientvaliderad data.

Figur 3. Transaktioner, stängt sigill och vittne.
Källa: LNP/BP Association Github.

Vi kan sammanfatta det så här: varje transaktion har en UTXO, och ägandet av denna UTXO ger ägaren rätten att besitta staten. Ägarskap avgör vem som kan ändra blockchain-tillståndet och "spendera" UTXO. Personen som innehar staten kallas part ägande stat.

Parten har befogenhet att modifiera den relevanta delen av det smarta kontraktstillståndet genom att generera en ny tillståndsövergång och bekräfta den i en transaktion, med användning av utdata som innehåller det tidigare tillståndet.

Processen betyder stängning av ett sigill över tillståndsövergångenoch ett par som omfattar utgiftstransaktionen och motsvarande extratransaktionsdata om tillståndsövergången kallas en Vittne (avbildad i en bild ovan).

Ägande och tillgång: Kärnegenskaper

Figur 4. Ägarskap och tillgång.
Källa: LNP/BP Association Github.

Statligt ägande och validering är distinkta begrepp. Valideringsregler anger hur staten kan förändras, medan de inte identifierar vem som kan verkställa förändringen. 

Å andra sidan kontrolleras ägandet av Bitcoin-skriptet på Bitcoin-blockkedjenivå, vilket inte är Turing Complete. Däremot styrs valideringsregler av RGB-schemat som använder Simplicity/Contractum Script, dvs. Turing Complete. 

RGB-schema

I RGB-smarta kontrakt tilldelas varje kontrakt ett unikt tillstånd genom engångssigill. Dessa sigill, tillsammans med staten, har specifika regler och valideringar, fastställda av kontraktets skapare i början. Denna inställning styrs av ett "schema", som fungerar som en uppsättning regler för att validera kontraktsdata på kundsidan. Schemat kan innehålla komplexa skript som är integrerade i kontraktets logik.

Figur 5. RGB-schema.
Källa: LNP/BP Association Github.

Validering och designprinciper på klientsidan

Figur 6. RGB Client-side-validation.
Källa: LNP/BP Association Github.

1. Starkt ägande: I RGB har smarta kontrakt ett tydligt defined ägare eller ägare. Endast utsedda ägare har befogenhet att ändra kontraktets tillstånd. Dessa kontrakt beskriver distinkta rättigheter eller verksamheter kategoriserade som antingen offentliga (tillgängliga för alla) eller ägda (begränsade till ägaren).
2. Sekretess: Informationen i kontraktet hålls konfidentiell, endast känd för deltagarna, särskilt statens ägare. Deltagare har möjlighet att göra viss data offentlig, men som standard är all information privat. Denna konfidentialitet förhindrar externa analysverktyg från att komma åt data, vilket säkerställer att ingen känslig information lagras i offentliga reskontra.
3. Dela upp problemen: RGB har en modulär design med distinkta lager, var och en tilldelad en specifik uppgift. Dessa skikt fungerar oberoende, vilket eliminerar behovet av att lägre skikt är medvetna om de högre skiktens struktur. Denna design förbättrar systemets organisation och effektivitet.
4. Sträckbarhet: Systemet är lätt att utöka, vilket möjliggör skapandet och integrationen av avancerade smarta kontrakt utan att behöva modifiera kärnprotokollet eller kompilera om hela RGB-biblioteket.
5. Determinism: RGB:s valideringslogik är deterministisk och ger konsekvent identiska resultat med samma ingångar och det rådande tillståndet för underliggande blockchain eller Lightning Network-kanal. Denna konsekvens uppnås genom två huvudkomponenter: a. Kärnvalideringslogiken, skriven i Rust, är densamma för alla system som kör RGB. b. Kontraktsspecifik valideringslogik körs på AluVM, en virtuell maskin som tillhandahåller en konsekvent uppsättning instruktioner oavsett plattform.
6. LNP/BP-interoperabilitet: RGB är designat för att fungera sömlöst med befintliga Bitcoin- och Lightning Network-tekniker. Den är också byggd för att vara kompatibel med framtida uppgraderingar av dessa tekniker.
   

Tillvägagångssätt för RGB och Pure Blockchain/L1-metoden

Rent blockchain/L1-upplägg är fel, konstaterar RGB-teamet.

Figur 7. RGB-kommentarer om Blockchain/L1-metoden.
Källa: LNP/BP Association Github.

RGB:s tillvägagångssätt: Deklarativ vs. imperativ programmering:

• De flesta blockchain-plattformar, inklusive Ethereum, använder smarta kontrakt skrivna i en imperativ stil. I detta tillvägagångssätt fungerar kontraktet som ett program som uttryckligen styr det steg-för-steg-utförande av uppgifter, som liknar ett exakt och detaljerat recept.
• Dessa imperativa program är ofta ganska restriktiva och begränsade av kapaciteten hos den underliggande blockchain-plattformen. Även om de ibland kallas Turing-kompletta, kommer de med betydande begränsningar.

Deklarativ karaktär av RGB-smarta kontrakt:

• RGB, å andra sidan, använder inte imperativ programmering. Istället använder den en speciell form av funktionell programmering där smarta kontrakt finns defined deklarativt.
• I deklarativ programmering beskriver man istället för att i detalj hur man gör något vad resultatet ska bli. Det är som att beskriva hur en måltid ska se ut snarare än att ge steg-för-steg matlagningsinstruktioner.
• "Schema" i RGB är ett deklarativt defiett smart kontrakt. Den specificerar reglerna och villkoren för kontraktet, men inte den exakta sekvensen av operationer för att uppnå dem.

Paradigmskifte i programmering:

• Att gå från Ethereums imperativa stil till RGB:s deklarativa stil inom smart kontraktsprogrammering liknar övergången från traditionell imperativ programmering till funktionell eller deklarativ programmering i allmän mjukvaruutveckling.
• Denna förändring kräver ett annat tänkesätt: att fokusera på "vad" (de önskade resultaten) snarare än "hur" (de specifika stegen för att uppnå dessa resultat).

Enkelhet

Den ursprungliga planen innebar att införliva Simplicity i RGB, och ansträngningar ägnades åt att säkerställa kompatibilitet från dag 1. Men med tanke på den tröga utvecklingen av Simplicity-utvecklingen och osäkerheten kring dess releasetidslinje, blev det uppenbart att det var opraktiskt att förlita sig på det. Den pågående RGB-utgåvan, som för närvarande håller på att förberedas, väckte frågor om Simplicitys inkludering.

Eftersom vi insåg avsaknaden av en tillförlitlig tidtabell för Simplicity, inledde vi en undersökning av alternativ (WASM, EVM (som ett skämt), IELE etc). Så småningom blev det uppenbart att utvecklingen av en proprietär virtuell maskin för RGB var det enda genomförbara alternativet, som ersatte det ursprungliga beroendet av Simplicity.

Därför bestämde vi oss för att skapa AluVM – ren funktionell, mycket bärbar Rust-baserad virtuell maskin för klient-side-validerade smarta kontrakt (RGB), Lightning Network, deterministisk distribuerad och edge computing.

prisma

PRISM står för "partially-replicated infinite state machines" databehandling.

RGB-teknik defines regler för att utveckla smarta kontrakt på en grundläggande nivå, kallad Schema, men det begränsar inte alla framtida åtgärder i kontraktet med en enda, övergripande algoritm. Istället utför varje nod på nätverket individuella operationer, och både kontraktets tillstånd och själva kontraktet förblir giltiga så länge som dessa operationer följer Schemats regler. 

Dessutom begränsar detta tillvägagångssätt inte kontraktets historiska utveckling med en förutbestämd algoritm. Således kan ett kontrakt uppvisa olika beteenden så länge som varje förändring uppfyller specifika valideringsregler. Denna metod fokuserar på lokala regler snarare än en global algoritm.

Däremot använder Ethereum en global algoritm där varje operation påverkar hela tillståndet för det smarta kontraktet. Med RGB arbetar du bara med en del av kontraktets tillstånd och tillämpar regler lokalt. Detta ger ett bredare utbud av möjligheter för kontraktsutveckling.

Nedan kan du se en översikt över skillnaderna mellan statliga kanaler och validering på klientsidan: 

Figur 8. Separering av distribuerade system.
Källa: LNP/BP Association Github.

Mer specifika skillnader är följande: 

Figur 9. Jämförelse av statliga kanaler och validering på klientsidan.
Källa: LNP/BP Association Github.

AluVM

AluVM – (algoritmisk logikenhet VM) är en ren och funktionell virtuell RISC-maskin designad för deterministiska bärbara datoruppgifter

AluVM utmärker sig genom att använda ett registerbaserat system som förbjuder slumpmässig minnesåtkomst. Denna design förbättrar AluVM:s lämplighet för applikationer som smarta kontrakt, fjärrkodexekvering och distribuerad och edge computing. Kärnstyrkorna hos AluVM ligger i dess determinism, robusthet och kapacitet för formell kodanalys.

Nyckelegenskaper: Exceptionless, Portabilitet, Sandboxing, Säkerhet, Utökningsbarhet.

Instruction Set Architecture (ISA) av AluVM är designad för att vara anpassningsbar, vilket gör att den kan skapa olika körtidsmiljöer för olika applikationer. AluVM i sig är en mycket förutsägbar, funktionell, registerbaserad virtuell maskin och ISA. 

Samtidigt som den begränsar åtkomst till slumpmässig minne, utmärker sig AluVM ISA i att utföra aritmetiska uppgifter, inklusive de som är relaterade till elliptiska kurvor. Unikt kan VM:s miljö utöka AluVM ISA, vilket möjliggör tillägg av funktioner som att ladda data till VM:s register och stödja specialiserade instruktioner (t.ex. SIMD) skräddarsydda för specifika applikationer.

AluVM är främst avsedd för användning i distribuerade system där konsistens och tillförlitlighet över olika plattformar är mer avgörande än bearbetningshastighet. De primära användningsområdena för AluVM, med rätt ISA-tillägg, inkluderar blockchain-teknik, beräkningar som är kritiska för konsensus i nätverk, edge computing, multiparty computing (som täcker deterministisk maskininlärning), klientsida-validering, begränsad Internet2-beräkning och genetiska algoritmer. Dessa applikationer drar nytta av AluVM:s förmåga att prestera konsekvent och säkert i olika miljöer.

Figur 10. AluVM-jämförelse.
Källa: LNP/BP Association Github.

Contractum

Contractum skiljer sig från andra smarta kontraktsprogrammeringsspråk genom att blanda Haskells funktionella kapacitet med närheten till den rena metallen som ses i Rust. Det upptar en nisch som tidigare var otillgänglig för smarta kontrakt:

Figur 11. Jämförelse av Contractum, Simplicity och andra språk.
Källa: contractum.org

Contractum är ett programmeringsspråk som används för att skapa RGB-kontrakt. Kontrakt gjorda med Contractum kontrolleras med en metod som kallas client-side-validation. Det här tillvägagångssättet lägger inte till några data till Bitcoin-blockkedjan, vilket kan jämföras med en form av skärningsteknik, ytterligare förbättrad med användning av noll-kunskapsbevis. 

Validering på klientsidan skiljer också kontraktets utveckling från blockchain-transaktioner, vilket gör det omöjligt att spåra eller analysera dessa transaktioner genom traditionella blockchain-analysmetoder.

Figur 12. Contractum funktioner.
Källa: contractum.org

För att engagera sig i Contractum-design är det viktigt att bekanta dig med de teknologier som används av RGB smarta kontrakt:

Figur 13. Tekniker som används av RGB-smarta kontrakt.
Källa: contractum.org

Senaste uppdateringar i ny version RGB v0.10

I den senaste versionen av RGB (version 0.10) har flera avancerade tekniska förbättringar implementerats, vilket förbättrar ramverkets möjligheter för komplex applikationsutveckling. Dessa uppdateringar fokuserar främst på införandet av en global stat för varje RGB-kontrakt, integrationen av kontraktsgränssnitt och antagandet av ett strikt typsystem.

Global State i RGB-kontrakt

Global State-funktionen är en kritisk innovation i RGB v0.10, som gör det möjligt för varje kontrakt att upprätthålla ett allmänt tillgängligt tillstånd. Detta tillstånd är tillgängligt inte bara för den virtuella RGB-maskinen utan även för externa klienter som plånböcker och andra applikationer.

Användbarheten av denna Global State är avgörande för att konstruera sofistikerade applikationer på RGB-plattformen, särskilt de som kräver intrikat tillståndshantering som syntetiska tillgångar och algoritmiska stabila mynt. Det möjliggör en mer dynamisk interaktion med kontraktets tillstånd, som sträcker sig bortom begränsningarna för traditionella smarta kontraktsarkitekturer.

Kontraktsgränssnitt

RGB v0.10 introducerar "kontraktsgränssnitt" som ett standardiserat kommunikationsprotokoll för olika smarta kontrakt. Dessa gränssnitt fungerar på samma sätt som Ethereums kontrakt ABI (Application Binary Interfaces) och ERC (Ethereum Request for Comments).

En viktig skillnad i RGB:s tillvägagångssätt är den icke-obligatoriska standardiseringen av dessa gränssnitt och deras inneboende paketering med kontrakt, vilket eliminerar behovet av separat distribution. Detta underlättar semantiskt medvetna interaktioner mellan användare och kontrakt via användargränssnitt i plånböcker och annan programvara.

Dessa gränssnitt är inte statiska; Utvecklare kan utöka befintliga kontrakt med ytterligare gränssnitt över tiden, vilket förbättrar funktionaliteten utan att ändra den oföränderliga kontraktskärnan.

Strikt typsystem

Det nya kodningsformatet i RGB v0.10 använder ett "strikt typer"-system. Detta system är en ny funktionell datatypsmetod designad för effektiv representation och introspektion av kontraktstillstånd inom RGB-ramverket.

Det strikta typsystemet säkerställer kompileringstidsförsäkran av datastorlekar, vilket är särskilt fördelaktigt för drift på resursbegränsade enheter, såsom low-end hårdvaruplånböcker med begränsad minneskapacitet.

Dessutom är hela RGB-konsensuslagret i version 0.10 kompilerat till strikta typer, vilket ger en grund för formella bevis på binär kompatibilitet över olika programvaruversioner. Denna funktion förenklar och säkrar inte bara användningen av RGB utan gör det också möjligt för tillgångsutgivare och kontraktsutvecklare att lägga till ytterligare metadata till sina tillgångar eller kontrakt. Sådan metadata kan spela en avgörande roll för att verifiera identiteten och äktheten av tillgångar eller kontrakt i RGB-ekosystemet.

Rostbaserade smarta kontrakt

RGB-smarta kontrakt kan nu skapas i Rust, vilket utnyttjar språkets kapacitet för typsäkerhet och prestanda.

Den strikta systemtypintegrationen underlättar direkt sammanställning av Rust-datatyper till RGB-kontraktsstrukturer, vilket förbättrar effektiviteten och tillförlitligheten hos kontraktskoden.

Förbättrade statliga introspektionsförmåga

Smarta kontrakt i RGB v0.10 kan introspektera sitt eget tillstånd inom valideringskoden som exekveras av den virtuella RGB-maskinen.

Den här funktionen är särskilt användbar för att skapa komplexa kontrakt som interagerar med Bitcoin-transaktioner, diskreta loggkontrakt och andra intrikata datastrukturer, vilket förbättrar omfattningen och funktionaliteten hos RGB-smarta kontrakt.

URL-baserat fakturaformat

Uppdateringen introducerar ett nytt fakturaformat som ersätter det tidigare Bech32m-kodade systemet.

Dessa nya URL-baserade fakturor är betydligt kortare och mer användarvänliga, vilket underlättar verifiering och automatisk öppning med förkonfigurerad programvara.

Stöd för WASM (WebAssembly).

RGB-standardbiblioteket är nu kompatibelt med miljöer som saknar I/O och filsystemåtkomst, såsom webbsidor eller webbläsarplugin.

Detta utökar de potentiella användningsfallen för RGB, vilket gör att den kan fungera sömlöst i ett brett utbud av webbaserade applikationer och tillägg.

Taproot Descriptors och Custom Derivation

RGB v0.10 använder taproot-baserade OP_RETURN-åtaganden (kallas tapret), vilket kräver stöd på deskriptornivå för plånböcker för att känna igen transaktioner med tweakade utdata.

Införandet av anpassade härledningsindex i den här versionen förhindrar icke-RGB-plånböcker från att oavsiktligt spendera utdata som innehåller RGB-tillgångar, vilket säkerställer integriteten hos dessa tillgångar.

Förenklade beroenden

RGB-konsensuslagret i version 0.10 har minskat dess beroenden, särskilt att gå bort från en anpassad skottsäker implementering som ursprungligen härrörde från Grin-projekt.

Denna minskning av beroenden förbättrar API:ns stabilitet och övergripande robusthet.

Strömlinjeformad integrationsprocess

Uppdateringen förenklar operativa arbetsflöden genom att minska behovet av flera API-anrop och komplex kodning av datastrukturer över flera språk.

RGB-kontraktstillstånd representeras nu som JSON-objekt, vilket möjliggör enkel serialisering över olika programmeringsspråk.

Förbättringar av användarupplevelsen

Den nya versionen av RGB förenklar användarupplevelsen genom att konsolidera tidigare disparata komponenter till ett enhetligt biblioteks-API och kommandoradsverktyg.

Även om RGB-noden fortfarande kan användas på hemmaservrar, är användningen inte längre obligatorisk för interaktion med RGB-systemet, vilket minskar inträdesbarriären för användare och plånboksapplikationer.

Det här avsnittet innehåller ett speciellt erkännande till Waterdrip Capital för att ha belyst de senaste funktionerna i deras stycke med titeln "Driving Mass Adoption of Crypto: How the RGB Protocol Illuminates the Future of Bitcoin."

RGB-konkurrenter

Figur 14. FRGB vs Ethereum i enkla ord.
Källa: LNP/BP Association Github

Pålrot

Taproot Assets, tidigare känt som Taro, är ett protokoll designat för att lansera tokens på Bitcoin-nätverket. Detta protokoll utnyttjar UTXO-modellen av Taproot tillsammans med tillhörande lösningar som Tapscript och taptweak. Dessa verktyg används för att lagra information om tillgången och balansen för en tillgång i Bitcoin-transaktionsdata.

Figur 15. Schema för att lagra information om Taproot Assets-tokens.
Källa: "Taproot Assets: issuing assets on Bitcoin" av Voltage

Taproot Assets använder en metod som är analog med Ordinals-konceptet, där BRC-20-tokens lagrar leveransinformation i metadata för uppräknade satoshis. Omvänt bäddar Taproot Assets in denna information i en Bitcoin-transaktions Taproot-utgång, med hjälp av vad som kallas ett "gles Merkle-träd". I huvudsak innehåller Taproot Assets ett Merkle-träd i Bitcoin-transaktionen, vilket fungerar som bevis på en specifik användares balans och den övergripande tokentillgången. Detta träd återspeglar i sin tur data från "Universum" - ett arkiv som upprätthåller hela tillgångshistoriken och hanteras av tokenutgivaren.

Figur 16. Digitalt tillståndsträd.
Källa: "Taproot Assets: issuing assets on Bitcoin" av Voltage

State Digital Tree – Arkitekturen för Taproot Assets erbjuder två alternativ för balansbevis: data utanför kedjan från universum eller det glesa Merkle-trädet inbäddat i UTXO.

Operativ mekanism

1. Tokenskaparen utför en P2TR-transaktion (Pay to Taproot) med hjälp av Taproot Assets-protokollet. 
2. Information om tillgången, i form av ett Merkle-träd, lagras i UTXO för denna transaktion (i själva verket genesis-blocket). 
3. För att överföra token, ändrar ägaren av Taproot-nyckeln saldoinformationen i Merkle-trädet, vilket säkerställer att den totala tillgången förblir konstant. 
4. Sådana ändringar införs via en ny Taproot-transaktion. För varje tokenöverföring krävs dock inte en separat transaktion i kedjan. I likhet med sammanslagningar eller Lightning Network tillåter protokollet ägaren att bearbeta en "batch" av överföringar och därefter publicera det uppdaterade tillståndet för saldon.

Fördelar med Taproot Assets

• En viktig fördel med Taproot Assets är dess fulla kompatibilitet med Lightning Network, vilket förbättrar skalbarhetsmöjligheterna och minskar transaktionskostnaderna.
• Taproot Assets skapar ett distinkt lager för inspelning av operationer med anpassade tokens. Även om den främst förlitar sig på data utanför kedjan, publicerar den statusen för saldon på huvudnätverket. 
• Detta tillvägagångssätt är mer flexibelt, skalbart och heltäckande jämfört med BRC-20, men det innebär också mer komplexitet för oerfarna användare.

BitVM

BitVM är ett banbrytande projekt som syftar till att omvandla Bitcoin till en helt decentraliserad datorplattform. BitVM-vitboken, som presenterades den 9 oktober 2023, introducerar en teknik som för närvarande är i testfasen och som kräver vidareutveckling för att nå sin fulla potential.

Kärnfunktionalitet och koncept för BitVM

I sin kärna använder BitVM konceptet med Optimistic Rollups för att externisera beräkningarna för smarta kontrakt från nätverket, och sedan utföra on-chain-verifiering baserad på "bedrägeribevis". Teoretiskt, när smart kontraktsinformation har registrerats i en Taproot-transaktion (som binär kod), är datautbyte och beräkningar avsedda att ske direkt mellan parterna. Detta tillvägagångssätt är utformat för att minska blockchain-stockning. Men om kontrollanten (parten som bevisar, d.v.s. kontraktsägaren) sänder felaktiga data, kan en verifierare initiera en kontroll i kedjan. Denna process utgör grunden för bedrägerisäkra koncept.

Hantera verifiering i kedjan i ett beräkningsmässigt begränsat nätverk

Utmaningen uppstår i hur man genomför en operationskontroll i ett nätverk som i sig inte stöder sådana beräkningar. För att hantera detta använder BitVM ett Merkle-träd för att skapa ett logiskt NAND-grindschema, som sedan registreras i en Taproot-transaktion. I huvudsak fungerar Merkle-trädet i transaktionsdatan som ett NAND-schema, där varje "gren" bär ett av två möjliga värden: 1 eller 0. Kedjeberäkningen fortsätter bit för bit, med utdata från en "gren" som blir input för nästa. Ständiga transaktionsutbyten för värdeverifiering sker mellan de smarta avtalsparterna. Om provarens beräkningsversion upptäcks felaktig, får verifieraren sina tillgångar låsta i Taproot-transaktionen.

Figur 17. Schematisk representation av NAND.
Källa: "The Big Deal with BitVM: Arbitrary Computation now possible on Bitcoin without a fork" av Bitcoin Magazine

Bygga NAND med pålrot och Merkle Tree

Detaljerad information om hur BitVM underlättar byggandet av NAND med Taproot- och Merkle-träd, samt dess inverkan på beräkningar, finns i den tekniska dokumentationen.

Detta tillvägagångssätt möjliggör en exakt, steg-för-steg-verifiering av smarta kontraktsberäkningar, i linje med principerna för blockchain-integritet och säkerhet.

Utmaningar med smart kontraktsbilateralism

Ett betydande problem kvarstår i BitVM på grund av den bilaterala strukturen av smarta kontrakt, vilket underlättar direkt datautbyte enbart mellan verifieraren och provaren, exklusive tredje parts inblandning. Denna begränsning hindrar utvecklingen av dApp och kräver kompletterande lösningar för flerpartskontraktskonstruktioner. 

Dessutom innebär de intrikata och låga egenskaperna hos BitVM att konstruktionen av funktionella produkter som utnyttjar denna grund kan sträcka sig över flera år. Betydande utveckling och innovation är absolut nödvändigt för att översätta denna grundläggande teknik till praktiska tillämpningar.

För en detaljerad djupdykning tveka inte att läsa en BitVM Whitepaper - https://bitvm.org/bitvm.pdf 

Slutsats

RGB-protokollet är en teknisk utveckling i Bitcoin-ekosystemet, som introducerar funktioner för smart kontraktsimplementering och utgivning av token direkt kopplat till Bitcoin-nätverket. Detta uppnås genom en kombination av validering på klientsidan och användning av sigill för engångsbruk, som länkar tokens till Bitcoins UTXO:er samtidigt som transaktionens integritet bibehålls.

En av de primära tekniska fördelarna med RGB är dess inställning till skalbarhet och integritet. Genom att flytta huvuddelen av valideringsarbetet från Bitcoin-blockkedjan och använda kryptografiska metoder för transaktionsverifiering, minskar RGB effektivt databördan på blockkedjan. Detta tillvägagångssätt bidrar till att upprätthålla effektiviteten i nätverket, särskilt när transaktionsvolymerna ökar.

RGB:s kompatibilitet med Lightning Network är en annan viktig aspekt som möjliggör mer skalbar och effektiv transaktionsbearbetning. Denna funktion är särskilt relevant med tanke på den växande efterfrågan på snabbare och mer kostnadseffektiva transaktionsmetoder i kryptovalutautrymmet.

Den komplexa karaktären hos RGB:s teknologi innebär dock utmaningar när det gäller användartillgänglighet och förståelse. Protokollets arkitektur och de avancerade kryptografiska metoder som används kan vara svåra att förstå och implementera, särskilt för dem som är nya inom blockchain-teknik. Denna komplexitet kan hindra bredare användning och användarengagemang.

Dessutom, medan RGB förbättrar integriteten genom att hålla kontraktsdata borta från blockkedjan, väcker denna aspekt också frågor om dataverifierbarhet och förmågan att granska transaktioner, vilket är avgörande för vissa applikationer och regelefterlevnad.

RGB:s senaste uppdatering, version 0.10, positionerar den som en anmärkningsvärd utmanare i det framväxande landskapet av blockchain-teknologier, särskilt mot framväxande protokoll som Taproot Assets och BitVM. Till skillnad från Taproot Assets, som fokuserar på att utnyttja UTXO-modellen av Taproot för tokenutgivning på Bitcoin-nätverket, utmärker sig RGB med sina avancerade integritetsfunktioner och off-chain datahantering, och erbjuder ett distinkt tillvägagångssätt för smart kontraktsfunktionalitet och tokenhantering.

På samma sätt, medan BitVM introducerar ett nytt koncept för decentraliserad datoranvändning på Bitcoin, visar RGB:s version 0.10-framsteg inom klientsidans validering, kontraktsgränssnitt och ett strikt typsystem dess unika tillvägagångssätt för att förbättra skalbarhet och användarinteraktion inom Bitcoin-ekosystemet. Dessa förbättringar framhäver RGB:s skicklighet när det gäller att hantera skalbarhets- och effektivitetsutmaningar, områden där traditionella och framväxande protokoll ofta möter begränsningar.

Förenklingen av beroenden och integrationsprocesser i RGB:s senaste version indikerar ytterligare ett fokus på användarupplevelse och systemstabilitet, vilket skiljer den från konkurrenterna. Detta positionerar RGB inte bara som en robust plattform för integritetsfokuserade och skalbara smarta kontrakt och utgivning av token utan också som en framåtblickande lösning i det bredare blockchain-utrymmet.

Sammanfattningsvis är RGB-protokollet en betydande teknisk utveckling inom Bitcoin-nätverket, som erbjuder avancerade möjligheter för smarta kontrakt och utfärdande av token. Den tar upp nyckelfrågor som skalbarhet och integritet men står inför utmaningar när det gäller komplexitet och potentiell granskningsbarhet. Den pågående utvecklingen och framtida iterationer av protokollet kommer sannolikt att fokusera på att balansera dessa avancerade funktioner med användartillgänglighet och regulatoriska överväganden.

Term referenser: 

1. Turing komplett: Rent praktiskt kan systemet utföra alla beräkningsproblem med tillräckligt med tid och minne. De flesta moderna programmeringsspråk är Turing-kompletta, vilket indikerar deras teoretiska förmåga att hantera alla beräkningsproblem.
   
2. schema: Ett kontraktsschema fungerar som den faktiska koden för ett smart kontrakt, som kan användas som en "kontraktsmall" av utfärdarna utan att behöva koda eller granska anpassad kod från externa källor. RGB-schema är inte ett skript utan är en datastruktur.
   
3. Diskreta loggkontrakt (DLC) i samband med statliga kanaler är specialiserade smarta kontrakt som främst används i Bitcoin-nätverket. De möjliggör privat och effektivt genomförande av komplexa finansiella avtal baserat på externa händelser, som tillgångspriser. DLC:er fungerar utanför kedjan och upprätthåller konfidentialitet för kontraktsdetaljer och deltagaridentiteter. De använder externa datakällor, eller orakel, för kontraktslösning. När de integreras med statliga kanaler förbättrar DLC skalbarheten genom att tillåta flera transaktionsavvecklingar utan att blockera blockkedjan, vilket gör dem idealiska för privata, effektiva finansiella transaktioner som beror på verkliga resultat.
   
4. Storm – depositionsbaserad trustless lagring med zk-proofs. Storm kombinerar depositionsbaserad trustless lagring med noll-kunskapsbevis för att underlätta säkra och privata transaktioner. I detta system hålls data eller tillgångar i deposition och släpps endast när specifika villkor är uppfyllda, vilket säkerställer en tillitslös miljö där ingen central myndighet behövs. Integrationen av zk-proofs möjliggör verifiering av dessa transaktioner med bibehållen största konfidentialitet, eftersom de möjliggör validering av data utan att avslöja några underliggande detaljer.
   
5. Prometheus – skiljedomsbaserad, förtroendelös distribuerad datoranvändning. Prometheus representerar ett tillvägagångssätt för decentraliserad datoranvändning, som kombinerar skiljedomsmekanismer för tvistlösning, tillitslösa interaktioner för säker och decentraliserad verksamhet och effektiviteten hos statliga kanaler för beräkningshantering utanför kedjan.
   
6. A Reducerad instruktionsuppsättning dator är en typ av mikroprocessorarkitektur som använder en liten, mycket optimerad uppsättning instruktioner snarare än den mycket specialiserade uppsättningen instruktioner som vanligtvis finns i andra arkitekturer.