RGB Magic Client Contracts on Bitcoin – Bitcoin Magazine
This is an opinion piece by Federico Tenga, a long-time contributor to Bitcoin projects with experience as an entrepreneur, consultant and educator.
Image source
The term “smart contracts” predates the invention of the blockchain and Bitcoin itself. Its first mention is in a 1994 article by 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 “
While delegating code execution to a global consensus network has advantages (e.g. the ease of deploying innocent contracts, such as the popular automated market makers), this design has a major flaw: lack of scalability (and privacy). If every node in a network must redundantly run the same code, the amount of code that can actually be executed without increasing the cost of running a node (thus preserving decentralization) remains too small, meaning that only a small number of contracts can be executed. executed.
But what if we could design a system where the terms of the contract are executed and validated only by the parties involved, rather than by all members of the network? Let’s imagine the example of a company that wants to issue shares. Instead of publishing the issuance contract publicly on a global ledger and using it to track all future transfers of ownership, it could simply issue the shares privately and give buyers the right to pass them on. Thereafter, the right to transfer ownership can be transferred to each new owner as if it were an amendment to the original issuing contract. In this way, each owner can independently verify that the shares he or she received are genuine by reading the original contract and validating that all history of changes that moved the shares match the rules of the original contract.
This is actually nothing new, it is actually the same mechanism used to transfer property before public registries became popular. In the UK, for example, it was not compulsory to register a property when ownership was transferred until the 90s. This means that over 15% of the land in England and Wales is still unregistered today. If you are buying an unregistered property, instead of checking in a register whether the seller is the true owner, you must confirm 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). By doing this, you must ensure that any property transfer has been correctly carried out 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 don’t have to trust the maintainer of the public land registry. On the other hand, it makes the verification of the seller’s ownership much more complicated for the buyer.
Source: Deed on unregistered real estate
How can transfer of unregistered properties be improved? First and foremost by making it a digitized process. If there is code that can be run by a computer to verify that all the history of ownership transfers conforms to the original contract rules, buying and selling will be much faster and cheaper.
Second, to avoid the risk of the seller duplicating his asset, a system of proof of publication must be implemented. For example, we could implement a rule that any transfer of ownership must be done in a predefined place in a known newspaper (eg put the hash of the transfer of ownership in the upper right corner of the front page of the New York Times). Since you cannot place the hash of a transfer in the same place twice, this prevents double use attempts. But using a well-known newspaper for this purpose has some disadvantages:
- You need to buy many newspapers for the verification process. Not very practical.
- Each contract needs its own place in the newspaper. Not very scalable.
- The newspaper editor can easily censor or, worse, simulate double spending by putting a random hash in your track, making any potential buyer of your asset think it has been sold before, and discouraging them from buying it. Not very distrustful.
For these reasons, there must be a better place to post proof of ownership transfers. And what better alternative 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 shouldn’t specify a fixed place in the block where the commitment to transfer ownership must happen (eg 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, specifically in a transaction originating from an unused transaction output (UTXO) to which the ownership of the asset to be issued is attached. The link between an asset and a bitcoin UTXO can occur either in the contract issuing 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 (ie 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 is 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 evidence that the ownership transfer is valid. This could be done in a number of ways, potentially even printing the proofs and sending them by carrier pigeon, which, while a bit inconvenient, would still do the job. But the best option to avoid censorship and privacy violations is to 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 evidence received from the other party.
This model just described for validated client-side contracts and ownership transfers is exactly what is 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 from a template, called a “form”, where the creator of the contract simply adjusts the parameters and ownership rights, as is done with traditional legal contracts. Currently, there are two types of schemes in RGB: one for issuing fungible tokens (RGB20) and another for issuing collectibles (RGB21), but in the future more schemes can be developed by anyone in a permissionless way without requiring protocol-level changes.
To use a more practical example, an issuer of fungible assets (eg company shares, stablecoins, etc.) can use the RGB20 schema template and create a contract that defines how many tokens it will issue, the name of the asset, and some additional metadata associated with it with that. It can then define which bitcoin UTXO has the right to transfer ownership of the tokens created and assign other rights to other UTXOs, such as the right to make a secondary issue or to renominate the asset. Each client receiving tokens created by this contract will be able to verify the contents of the Genesis contract and validate that any transfer of ownership in the history of the token received has complied with the rules set forth therein.
So what can we do with RGB in practice today? First and foremost, it enables the issuance and transfer of tokenized assets with better scalability and privacy compared to all existing alternatives. 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 the blinded UTXO (ie the hash of the pairing between the UTXO in which she wants to receive the assets and a random number) instead of the UTXO itself, so it is not possible for the payer to monitor the future activities of the recipient. 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 a clear view of the financial behavior of previous owners.
In terms of scalability, RGB also offers some advantages. First, most of the data is kept off-chain, since the blockchain is only used as a commitment layer, which reduces the fees that need to be paid and means 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 savings 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 the “rights”) associated with a UTXO towards any number of recipients with a single commitment in a single bitcoin transaction. Let’s assume that you are a service provider that makes payments to several users at the same time. With RGB, in a single Bitcoin transaction, you can make thousands of transfers to thousands of users requesting different types of assets, making the marginal cost of each payout completely negligible.
Another fee-saving mechanism for issuers of low-value assets is that in the RGB, issuing 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 which pre-existing UTXO the newly issued assets will be allocated to. So if you’re 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. Although not yet implemented at the time of writing, it will be possible to create asset-specific Lightning channels and route payments through them, the same way it works with regular Lightning transactions.
Conclusion
RGB is a breakthrough innovation that opens up new use cases using a whole new paradigm, but what tools are available to use it? If you want to experiment with the very core of the technology, you should try out the RGB node directly. If you want to build applications on top of RGB without having to delve into the complexities of the protocol, you can use the rgb-lib library, which provides a simple interface for developers. If you just want to try issuing and transferring assets, you can play with Iris Wallet for Android, whose code is also open source on GitHub. If you just want to learn more about RGB, check out this list of resources.
This is a guest post by Federico Tenga. Opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
