RGB Magic: Contracten aan klantzijde op Bitcoin

Dit is een opinieredactioneel commentaar van Federico Tenga, die al lange tijd bijdraagt ​​aan Bitcoin-projecten met ervaring als start-up-oprichter, consultant en docent.

De term "slimme contracten" dateert van vóór de uitvinding van de blockchain en Bitcoin zelf. De eerste vermelding is in een Artikel uit 1994 van Nick Szabo, die slimme contracten definieerde als een 'geautomatiseerd transactieprotocol dat de voorwaarden van een contract uitvoert'. Terwijl volgens deze definitie Bitcoin, dankzij zijn scripttaal, slimme contracten vanaf het allereerste blok ondersteunde, werd de term pas later gepopulariseerd door Ethereum-promotors, die de oorspronkelijke definitie verdraaiden als "code die redundant wordt uitgevoerd door alle knooppunten in een wereldwijde consensus". netwerk"

Hoewel het delegeren van de uitvoering van code aan een wereldwijd consensusnetwerk voordelen heeft (het is bijvoorbeeld gemakkelijk om contracten zonder contract te implementeren, zoals de vaak geautomatiseerde marktmakers), heeft dit ontwerp één grote tekortkoming: gebrek aan schaalbaarheid (en privacy). Als elk knooppunt in een netwerk redundant dezelfde code moet uitvoeren, blijft de hoeveelheid code die daadwerkelijk kan worden uitgevoerd zonder de exploitatiekosten van een knooppunt buitensporig te verhogen (en dus de decentralisatie te behouden) schaars, wat betekent dat slechts een klein aantal contracten kan worden uitgevoerd. uitgevoerd.

Maar wat als we een systeem zouden kunnen ontwerpen waarbij de voorwaarden van het contract alleen worden uitgevoerd en gevalideerd door de betrokken partijen, in plaats van door alle leden van het netwerk? Laten we ons het voorbeeld voorstellen van een bedrijf dat aandelen wil uitgeven. In plaats van het uitgiftecontract openbaar te publiceren op een grootboek en dat grootboek te gebruiken om alle toekomstige eigendomsoverdrachten bij te houden, zou het de aandelen eenvoudig onderhands kunnen uitgeven en aan de kopers het recht kunnen overdragen om ze verder over te dragen. Vervolgens kan het recht om het eigendom over te dragen aan elke nieuwe eigenaar worden overgedragen alsof het een wijziging van het oorspronkelijke uitgiftecontract betreft. Op deze manier kan elke eigenaar onafhankelijk verifiëren dat de aandelen die hij of zij heeft ontvangen echt zijn door het oorspronkelijke contract te lezen en te valideren dat de hele geschiedenis van wijzigingen die de aandelen hebben verplaatst, in overeenstemming is met de regels die in het oorspronkelijke contract zijn uiteengezet.

Dit is eigenlijk niets nieuws, het is inderdaad hetzelfde mechanisme dat werd gebruikt om eigendom over te dragen voordat openbare registers populair werden. In het Verenigd KoninkrijkZo was het tot in de jaren '90 niet verplicht om een ​​woning te registreren bij de eigendomsoverdracht. Dit betekent dat nog steeds meer dan 15% van het land in Engeland en Wales niet is geregistreerd. Als u een niet-geregistreerd onroerend goed koopt, moet u in plaats van in een register te controleren of de verkoper de echte eigenaar is, een ononderbroken eigendomsketen verifiëren die ten minste 15 jaar teruggaat (een periode die lang genoeg wordt geacht om aan te nemen dat de verkoper voldoende titel van het onroerend goed). Daarbij moet u ervoor zorgen dat een eventuele eigendomsoverdracht correct is uitgevoerd en dat eventuele hypotheken die zijn gebruikt voor eerdere transacties volledig zijn afgelost. Dit model heeft het voordeel van verbeterde privacy ten opzichte van eigendom, en u hoeft niet te vertrouwen op de beheerder van het openbare kadaster. Aan de andere kant maakt het de verificatie van het eigendom van de verkoper veel ingewikkelder voor de koper.

Hoe kan de overdracht van niet-geregistreerde eigendommen worden verbeterd? Ten eerste door er een gedigitaliseerd proces van te maken. Als er code is die door een computer kan worden uitgevoerd om te verifiëren dat de hele geschiedenis van eigendomsoverdrachten in overeenstemming is met de oorspronkelijke contractregels, wordt kopen en verkopen veel sneller en goedkoper.

Ten tweede, om het risico te vermijden dat de verkoper zijn activa dubbel uitgeeft, moet een systeem van bewijs van publicatie worden geïmplementeerd. We zouden bijvoorbeeld een regel kunnen implementeren dat elke eigendomsoverdracht moet plaatsvinden op een vooraf bepaalde plek in een bekende krant (plaats bijvoorbeeld de hasj van de eigendomsoverdracht in de rechterbovenhoek van de eerste pagina van de New York Keer). Aangezien je de hash van een overboeking niet twee keer op dezelfde plek kunt plaatsen, voorkom je dubbele bestedingspogingen. Het gebruik van een bekende krant voor dit doel heeft echter enkele nadelen:

1. Je moet veel kranten kopen voor het verificatieproces. Niet erg praktisch.
2. Elk contract heeft zijn eigen plek in de krant nodig. Niet erg schaalbaar.
3. De redacteur van de krant kan gemakkelijk dubbele uitgaven censureren of, nog erger, simuleren door een willekeurige hasj in uw slot te stoppen, waardoor potentiële kopers van uw bezit denken dat het al eerder is verkocht en hen ontmoedigen om het te kopen. Niet erg betrouwbaar.

Om deze redenen moet er een betere plek worden gevonden om bewijs van eigendomsoverdracht te posten. En wat is een betere optie dan de Bitcoin-blockchain, een reeds gevestigd vertrouwd grootboek met sterke prikkels om het censuurbestendig en gedecentraliseerd te houden?

Als we Bitcoin gebruiken, moeten we geen vaste plaats in het blok specificeren waar de toezegging tot eigendomsoverdracht moet plaatsvinden (bijvoorbeeld in de eerste transactie) omdat, net als bij de redacteur van de New York Times, de miner ermee zou kunnen rommelen. Een betere aanpak is om de commitment te plaatsen in een vooraf gedefinieerde Bitcoin-transactie, meer specifiek in een transactie die voortkomt uit een unspended transaction output (UTXO) waaraan het eigendom van het uit te geven activum is gekoppeld. De link tussen een activum en een bitcoin UTXO kan voorkomen in het contract dat het activum uitgeeft of in een daaropvolgende eigendomsoverdracht, waarbij de doel-UTXO telkens de controller van het overgedragen activum wordt. Op deze manier hebben we duidelijk gedefinieerd waar de verplichting tot eigendomsoverdracht zou moeten zijn (dwz in de Bitcoin-transactie die afkomstig is van een bepaalde UTXO). Iedereen die een Bitcoin-node runt, kan de toezeggingen onafhankelijk verifiëren en noch de mijnwerkers, noch enige andere entiteit kan de overdracht van activa op enigerlei wijze censureren of verstoren.

Aangezien we op de Bitcoin-blockchain alleen een toezegging van een eigendomsoverdracht publiceren, niet de inhoud van de overdracht zelf, heeft de verkoper een speciaal communicatiekanaal nodig om de koper alle bewijzen te geven dat de eigendomsoverdracht geldig is. Dit kan op een aantal manieren worden gedaan, mogelijk zelfs door de proefdrukken af ​​te drukken en ze met een postduif te verzenden, wat, hoewel een beetje onpraktisch, nog steeds het werk zou doen. Maar de beste optie om de censuur en schendingen van de privacy te vermijden, is een directe peer-to-peer gecodeerde communicatie tot stand te brengen, die in vergelijking met de duiven ook het voordeel heeft dat het gemakkelijk te integreren is met software om de van de tegenpartij ontvangen bewijzen te verifiëren.

Dit zojuist beschreven model voor gevalideerde contracten en eigendomsoverdrachten aan de klantzijde is precies wat is geïmplementeerd met het RGB-protocol. Met RGB is het mogelijk om een ​​contract te maken dat rechten definieert, deze toewijst aan een of meer bestaande bitcoin UTXO en specificeert hoe hun eigendom kan worden overgedragen. Het contract kan worden gemaakt uitgaande van een sjabloon, een "schema" genaamd, waarin de maker van het contract alleen de parameters en eigendomsrechten aanpast, zoals bij traditionele juridische contracten. Momenteel zijn er twee soorten schema's in RGB: een voor het uitgeven van vervangbare tokens (RGB20) en een tweede voor het uitgeven van verzamelobjecten (RGB21), maar in de toekomst kunnen meer schema's door iedereen zonder toestemming worden ontwikkeld zonder dat er wijzigingen op protocolniveau nodig zijn.

Om een ​​praktischer voorbeeld te gebruiken: een uitgever van vervangbare activa (bijv. bedrijfsaandelen, stablecoins, enz.) kan de RGB20-schemasjabloon gebruiken en een contract opstellen waarin wordt vastgelegd hoeveel tokens hij zal uitgeven, de naam van het activum en enkele bijbehorende metadata. ermee. Het kan vervolgens bepalen welke bitcoin UTXO het recht heeft om het eigendom van de gecreëerde tokens over te dragen en andere rechten toewijzen aan andere UTXO's, zoals het recht om een ​​secundaire uitgifte te doen of om het activum te hernomineren. Elke klant die tokens ontvangt die door dit contract zijn gemaakt, kan de inhoud van het Genesis-contract verifiëren en valideren dat elke overdracht van eigendom in de geschiedenis van het ontvangen token heeft voldaan aan de daarin uiteengezette regels.

Dus wat kunnen we vandaag in de praktijk met RGB doen? Eerst en vooral maakt het de uitgifte en overdracht van tokenized activa mogelijk met betere schaalbaarheid en privacy in vergelijking met elk bestaand alternatief. Aan de privacykant profiteert RGB van het feit dat alle overdrachtsgerelateerde gegevens aan de clientzijde worden bewaard, zodat een blockchain-waarnemer geen informatie over de financiële activiteiten van de gebruiker kan extraheren (het is zelfs niet mogelijk om een ​​bitcoin-transactie te onderscheiden die een RGB-toezegging bevat van een reguliere), bovendien deelt de ontvanger met de afzender alleen geblindeerde UTXO (dwz de hash van de aaneenschakeling tussen de UTXO waarin ze de activa wil ontvangen en een willekeurig nummer) in plaats van de UTXO zelf, dus het is niet mogelijk voor de betaler om toekomstige activiteiten van de ontvanger te volgen. Om de privacy van gebruikers verder te vergroten, past RGB ook het kogelvrije cryptografische mechanisme toe om de bedragen in de geschiedenis van vermogensoverdrachten te verbergen, zodat zelfs toekomstige eigenaars van activa een vertroebeld beeld hebben van het financiële gedrag van eerdere houders.

Op het gebied van schaalbaarheid biedt RGB ook enkele voordelen. Allereerst worden de meeste gegevens off-chain bewaard, aangezien de blockchain alleen wordt gebruikt als een commitment-laag, waardoor de kosten die moeten worden betaald, worden verlaagd en wat betekent dat elke klant alleen de overdrachten valideert waarin hij geïnteresseerd is in plaats van alle activiteit van een wereldwijd netwerk. Aangezien voor een RGB-overdracht nog steeds een Bitcoin-transactie nodig is, lijkt de kostenbesparing misschien minimaal, maar wanneer u begint met het introduceren van transactiebatches, kunnen deze al snel enorm worden. Het is inderdaad mogelijk om alle tokens (of, meer in het algemeen, "rechten") die aan een UTXO zijn gekoppeld, over te dragen naar een willekeurig aantal ontvangers met een enkele toezegging in een enkele bitcoin-transactie. Laten we aannemen dat u een dienstverlener bent die uitbetalingen doet aan meerdere gebruikers tegelijk. Met RGB kunt u in een enkele Bitcoin-transactie duizenden overschrijvingen doen naar duizenden gebruikers die om verschillende soorten activa vragen, waardoor de marginale kosten van elke afzonderlijke uitbetaling absoluut te verwaarlozen zijn.

Een ander vergoedingsbesparend mechanisme voor emittenten van activa met een lage waarde is dat in RGB voor de uitgifte van een activum geen vergoeding vereist is. Dit gebeurt omdat het creëren van een uitgiftecontract niet hoeft te worden vastgelegd op de blockchain. Een contract definieert simpelweg aan welke reeds bestaande UTXO de nieuw uitgegeven activa zullen worden toegewezen. Dus als je een artiest bent die geïnteresseerd is in het maken van verzamelbare tokens, kun je er zoveel gratis uitgeven als je wilt en betaal je alleen de bitcoin-transactiekosten wanneer een koper verschijnt en verzoekt om het token toe te wijzen aan zijn UTXO.

Omdat RGB bovenop bitcoin-transacties is gebouwd, is het bovendien ook compatibel met het Lightning Network. Hoewel het op het moment van schrijven nog niet is geïmplementeerd, is het mogelijk om activaspecifieke Lightning-kanalen te maken en betalingen via deze kanalen te routeren, vergelijkbaar met hoe het werkt met normale Lightning-transacties.

Conclusie

RGB is een baanbrekende innovatie die zich opent voor nieuwe use-cases met behulp van een volledig nieuw paradigma, maar welke tools zijn er beschikbaar om het te gebruiken? Als je wilt experimenteren met de kern van de technologie zelf, moet je de RGB-knooppunt. Als u applicaties bovenop RGB wilt bouwen zonder diep in de complexiteit van het protocol te hoeven duiken, kunt u de rgb-lib-bibliotheek, dat een eenvoudige interface biedt voor ontwikkelaars. Als u alleen maar wilt proberen activa uit te geven en over te dragen, kunt u spelen met Iris-portemonnee voor Android, waarvan de code ook open source is op GitHub. Als je gewoon meer wilt weten over RGB, kun je uitchecken deze lijst met bronnen.

Dit is een gastpost van Federico Tenga. Geuite meningen zijn volledig van henzelf en komen niet noodzakelijkerwijs overeen met die van BTC Inc of Bitcoin Magazine.