RGB Magic: Kontrakter på klientsiden på Bitcoin

This is an opinion editorial by Federico Tenga, a long time contributor to Bitcoin projects with experience as start-up founder, consultant and educator.

The term “smart contracts” predates the invention of the blockchain and Bitcoin itself. Its first mention is in a Artikel fra 1994 af Nick Szabo, who defined smart contracts as a “computerized transaction protocol that executes the terms of a contract.” While by this definition Bitcoin, thanks to its scripting language, supported smart contracts from the very first block, the term was popularized only later by Ethereum promoters, who twisted the original definition as “code that is redundantly executed by all nodes in a global consensus network”

Selvom uddelegering af kodeeksekvering til et globalt konsensusnetværk har fordele (f.eks. er det nemt at implementere uskyldige kontrakter, såsom de populært automatiserede market makers), har dette design en stor fejl: mangel på skalerbarhed (og privatliv). Hvis hver knude i et netværk redundant skal køre den samme kode, er mængden af ​​kode, der rent faktisk kan udføres uden at øge omkostningerne ved at køre en knude (og dermed bevare decentraliseringen) overdreven knap, hvilket betyder, at kun et lille antal kontrakter kan udføres. henrettet.

Men hvad nu hvis vi kunne designe et system, hvor vilkårene i kontrakten kun udføres og valideres af de involverede parter, snarere end af alle medlemmer af netværket? Lad os forestille os eksemplet med en virksomhed, der ønsker at udstede aktier. I stedet for at offentliggøre udstedelseskontrakten offentligt på en global hovedbog og bruge den til at spore alle fremtidige overdragelser af ejerskab, kunne den simpelthen udstede aktierne privat og give køberne retten til yderligere at overføre dem. Herefter kan retten til at overdrage ejendomsretten overdrages til hver ny ejer, som var det en ændring af den oprindelige udstedelseskontrakt. På denne måde kan hver ejer uafhængigt verificere, at de aktier, han eller hun modtog, er ægte ved at læse den oprindelige kontrakt og validere, at hele historikken for ændringer, der flyttede aktierne, er i overensstemmelse med reglerne i den oprindelige kontrakt.

Dette er faktisk ikke noget nyt, det er faktisk den samme mekanisme, som blev brugt til at overføre ejendom, før offentlige registre blev populære. I Storbritannien, for example, it was not compulsory to register a property when its ownership was transferred until the ‘90s. This means that still today over 15% of land in England and Wales is unregistered. If you are buying an unregistered property, instead of checking on a registry if the seller is the true owner, you would have to verify an unbroken chain of ownership going back at least 15 years (a period considered long enough to assume that the seller has sufficient title to the property). In doing so, you must ensure that any transfer of ownership has been carried out correctly and that any mortgages used for previous transactions have been paid off in full. This model has the advantage of improved privacy over ownership, and you do not have to rely on the maintainer of the public land register. On the other hand, it makes the verification of the seller’s ownership much more complicated for the buyer.

Hvordan kan overdragelsen af ​​uregistrerede ejendomme forbedres? Først og fremmest ved at gøre det til en digitaliseret proces. Hvis der er kode, der kan køres af en computer for at verificere, at hele historien om ejerskabsoverdragelser er i overensstemmelse med de oprindelige kontraktregler, bliver køb og salg meget hurtigere og billigere.

For det andet, for at undgå risikoen for, at sælgeren dobbeltbruger deres aktiv, skal der implementeres et system med bevis for offentliggørelse. For eksempel kunne vi implementere en regel om, at enhver overdragelse af ejerskab skal foretages på et foruddefineret sted i en velkendt avis (f.eks. sæt hashen for overdragelsen af ​​ejerskab i øverste højre hjørne af den første side af New York gange). Da du ikke kan placere hashen af ​​en overførsel det samme sted to gange, forhindrer dette dobbeltforbrugsforsøg. Men at bruge en berømt avis til dette formål har nogle ulemper:

1. You have to buy a lot of newspapers for the verification process. Not very practical.
2. Each contract needs its own space in the newspaper. Not very scalable.
3. The newspaper editor can easily censor or, even worse, simulate double-spending by putting a random hash in your slot, making any potential buyer of your asset think it has been sold before, and discouraging them from buying it. Not very trustless.

For these reasons, a better place to post proof of ownership transfers needs to be found. And what better option than the Bitcoin blockchain, an already established trusted public ledger with strong incentives to keep it censorship-resistant and decentralized?

If we use Bitcoin, we should not specify a fixed place in the block where the commitment to transfer ownership must occur (e.g. in the first transaction) because, just like with the editor of the New York Times, the miner could mess with it. A better approach is to place the commitment in a predefined Bitcoin transaction, more specifically in a transaction that originates from an unspent transaction output (UTXO) to which the ownership of the asset to be issued is linked. The link between an asset and a bitcoin UTXO can occur either in the contract that issues the asset or in a subsequent transfer of ownership, each time making the target UTXO the controller of the transferred asset. In this way, we have clearly defined where the obligation to transfer ownership should be (i.e in the Bitcoin transaction originating from a particular UTXO). Anyone running a Bitcoin node can independently verify the commitments and neither the miners nor any other entity are able to censor or interfere with the asset transfer in any way.

Since on the Bitcoin blockchain we only publish a commitment of an ownership transfer, not the content of the transfer itself, the seller needs a dedicated communication channel to provide the buyer with all the proofs that the ownership transfer is valid. This could be done in a number of ways, potentially even by printing out the proofs and shipping them with a carrier pigeon, which, while a bit impractical, would still do the job. But the best option to avoid the censorship and privacy violations is establish a direct peer-to-peer encrypted communication, which compared to the pigeons also has the advantage of being easy to integrate with a software to verify the proofs received from the counterparty.

This model just described for client-side validated contracts and ownership transfers is exactly what has been implemented with the RGB protocol. With RGB, it is possible to create a contract that defines rights, assigns them to one or more existing bitcoin UTXO and specifies how their ownership can be transferred. The contract can be created starting from a template, called a “schema,” in which the creator of the contract only adjusts the parameters and ownership rights, as is done with traditional legal contracts. Currently, there are two types of schemas in RGB: one for issuing fungible tokens (RGB20) og en anden for at udstede samleobjekter (RGB21), men i fremtiden kan flere skemaer udvikles af enhver på en tilladelsesfri måde uden at kræve ændringer på protokolniveau.

To use a more practical example, an issuer of fungible assets (e.g. company shares, stablecoins, etc.) can use the RGB20 schema template and create a contract defining how many tokens it will issue, the name of the asset and some additional metadata associated with it. It can then define which bitcoin UTXO has the right to transfer ownership of the created tokens and assign other rights to other UTXOs, such as the right to make a secondary issuance or to renominate the asset. Each client receiving tokens created by this contract will be able to verify the content of the Genesis contract and validate that any transfer of ownership in the history of the token received has complied with the rules set out therein.

So what can we do with RGB in practice today? First and foremost, it enables the issuance and the transfer of tokenized assets with better scalability and privacy compared to any existing alternative. On the privacy side, RGB benefits from the fact that all transfer-related data is kept client-side, so a blockchain observer cannot extract any information about the user’s financial activities (it is not even possible to distinguish a bitcoin transaction containing an RGB commitment from a regular one), moreover, the receiver shares with the sender only blinded UTXO (i. e. the hash of the concatenation between the UTXO in which she wish to receive the assets and a random number) instead of the UTXO itself, so it is not possible for the payer to monitor future activities of the receiver. To further increase the privacy of users, RGB also adopts the bulletproof cryptographic mechanism to hide the amounts in the history of asset transfers, so that even future owners of assets have an obfuscated view of the financial behavior of previous holders.

In terms of scalability, RGB offers some advantages as well. First of all, most of the data is kept off-chain, as the blockchain is only used as a commitment layer, reducing the fees that need to be paid and meaning that each client only validates the transfers it is interested in instead of all the activity of a global network. Since an RGB transfer still requires a Bitcoin transaction, the fee saving may seem minimal, but when you start introducing transaction batching they can quickly become massive. Indeed, it is possible to transfer all the tokens (or, more generally, “rights”) associated with a UTXO towards an arbitrary amount of recipients with a single commitment in a single bitcoin transaction. Let’s assume you are a service provider making payouts to several users at once. With RGB, you can commit in a single Bitcoin transaction thousands of transfers to thousands of users requesting different types of assets, making the marginal cost of each single payout absolutely negligible.

Another fee-saving mechanism for issuers of low value assets is that in RGB the issuance of an asset does not require paying fees. This happens because the creation of an issuance contract does not need to be committed on the blockchain. A contract simply defines to which already existing UTXO the newly issued assets will be allocated to. So if you are an artist interested in creating collectible tokens, you can issue as many as you want for free and then only pay the bitcoin transaction fee when a buyer shows up and requests the token to be assigned to their UTXO.

Furthermore, because RGB is built on top of bitcoin transactions, it is also compatible with the Lightning Network. While it is not yet implemented at the time of writing, it will be possible to create asset-specific Lightning channels and route payments through them, similar to how it works with normal Lightning transactions.

Konklusion

RGB er en banebrydende innovation, der åbner op for nye use cases ved hjælp af et helt nyt paradigme, men hvilke værktøjer er tilgængelige til at bruge det? Hvis du vil eksperimentere med selve kernen af ​​teknologien, bør du direkte prøve den RGB node. Hvis du vil bygge applikationer oven på RGB uden at skulle dykke ned i kompleksiteten af ​​protokollen, kan du bruge rgb-lib bibliotek, som giver en enkel grænseflade til udviklere. Hvis du bare vil prøve at udstede og overføre aktiver, kan du spille med Iris Wallet til Android, hvis kode også er open source på GitHub. Hvis du bare vil lære mere om RGB, kan du tjekke ud denne liste over ressourcer.

This is a guest post by Federico Tenga. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.