RGB Magic: Client-Side Contracts On Bitcoin

This is a viewpoint editorial by Federico Tenga, a long time factor to Bitcoin projects with experience as start-up creator, specialist and educator.Image sourceThe term “wise agreements” predates the innovation of the blockchain and Bitcoin itself. Its very first reference remains in a 1994 article by Nick Szabo, who specified smart agreements as a “electronic deal procedure that executes the terms of an agreement.” While by this meaning Bitcoin, thanks to its scripting language, supported clever contracts from the very first block, the term was promoted just later by Ethereum promoters, who twisted the original definition as “code that is redundantly performed by all nodes in an international agreement network”While handing over code execution to a worldwide consensus network has advantages (e.g. it is simple to deploy unowed agreements, such as the popularly automated market makers), this style has one significant flaw: absence of scalability (and personal privacy). If every node in a network must redundantly run the same code, the quantity of code that can really be carried out without excessively increasing the cost of running a node (and thus preserving decentralization) remains scarce, implying that just a little number of agreements can be executed.But what if we could design a system where the regards to the contract are performed and confirmed just by the celebrations involved, instead of by all members of the network? Let us think of the example of a business that wants to issue shares. Instead of publishing the issuance agreement openly on an international ledger and using that ledger to track all future transfers of ownership, it might just release the shares privately and pass to the purchasers the right to further transfer them. Then, the right to transfer ownership can be handed down to each new owner as if it were a change to the original issuance contract. In this way, each owner can individually confirm that the shares he or she got are genuine by checking out the original contract and verifying that all the history of modifications that moved the shares comply with the rules state in the initial contract.This is actually absolutely nothing new, it is indeed the same system that was used to move residential or commercial property before public registers became popular. In the U.K., for instance, it was not compulsory to register a home when its ownership was moved till the 90s. This indicates that still today over 15% of land in England and Wales is unregistered. If you are purchasing an unregistered residential or commercial property, rather of looking at a pc registry if the seller is the true owner, you would need to verify an unbroken chain of ownership going back at least 15 years (a duration thought about enough time to assume that the seller has adequate title to the home). In doing so, you should make sure that any transfer of ownership has actually been carried out correctly which any home mortgages used for previous transactions have been paid off in complete. This design has the benefit of improved privacy over ownership, and you do not need to count on the maintainer of the general public land register. On the other hand, it makes the verification of the sellers ownership far more made complex for the buyer.Source: Title deed of unregistered realty proprietyHow can the transfer of unregistered properties be enhanced? Firstly, by making it a digitized process. If there is code that can be run by a computer system to validate that all the history of ownership transfers remains in compliance with the original agreement rules, buying and selling ends up being much faster and cheaper.Secondly, to prevent the danger of the seller double-spending their possession, a system of proof of publication should be implemented. For instance, we could implement a rule that every transfer of ownership need to be committed on a predefined area of a well-known paper (e.g. put the hash of the transfer of ownership in the upper-right corner of the first page of the New York Times). Since you can not position the hash of a transfer in the very same place two times, this prevents double-spending attempts. Utilizing a popular newspaper for this purpose has some downsides: You have to purchase a lot of papers for the verification process. Not really practical.Each contract requires its own space in the newspaper. Not very scalable.The newspaper editor can easily censor or, even worse, imitate double-spending by putting a random hash in your slot, making any prospective buyer of your asset think it has been offered previously, and dissuading them from buying it. Not very trustless.For these reasons, a better place to publish evidence of ownership transfers requires to be discovered. And what better alternative than the Bitcoin blockchain, a currently developed trusted public ledger with strong incentives to keep it censorship-resistant and decentralized?If we utilize Bitcoin, we need to not specify a fixed location in the block where the commitment to transfer ownership needs to occur (e.g. in the first transaction) because, simply like with the editor of the New York Times, the miner might tinker it. A better approach is to place the commitment in a predefined Bitcoin transaction, more particularly in a deal that originates from an unspent deal output (UTXO) to which the ownership of the property to be released is connected. The link between an asset and a bitcoin UTXO can happen either in the agreement that provides the possession or in a subsequent transfer of ownership, each time making the target UTXO the controller of the transferred property. In this method, we have plainly specified where the commitment to move ownership must be (i.e in the Bitcoin deal originating from a particular UTXO). Anybody running a Bitcoin node can independently validate the dedications and neither the miners nor any other entity have the ability to censor or interfere with the property transfer in any way.Since on the Bitcoin blockchain we just publish a dedication of an ownership transfer, not the content of the transfer itself, the seller needs a dedicated communication channel to supply the purchaser with all the evidence that the ownership transfer is valid. This might be carried out in a variety of methods, potentially even by printing out the proofs and delivering them with a provider pigeon, which, while a bit not practical, would still do the task. The best choice to prevent the censorship and privacy violations is establish a direct peer-to-peer encrypted communication, which compared to the pigeons likewise has the benefit of being easy to integrate with a software application to validate the evidence received from the counterparty.This design simply described for client-side confirmed contracts and ownership transfers is exactly what has been executed with the RGB procedure. With RGB, it is possible to develop a contract that defines rights, designates them to one or more existing bitcoin UTXO and defines how their ownership can be moved. The agreement can be produced beginning from a design template, called a “schema,” in which the creator of the contract only changes the parameters and ownership rights, as is done with conventional legal agreements. Presently, there are two kinds of schemas in RGB: one for providing fungible tokens (RGB20) and a 2nd for issuing collectibles (RGB21), however in the future, more schemas can be developed by anybody in a permissionless style without requiring modifications at the procedure level.To use a more useful example, an issuer of fungible properties (e.g. business shares, stablecoins, and so on) can use the RGB20 schema design template and produce an agreement defining how lots of tokens it will release, the name of the property and some extra metadata related to it. It can then specify which bitcoin UTXO deserves to transfer ownership of the produced tokens and assign other rights to other UTXOs, such as the right to make a secondary issuance or to renominate the asset. Each customer receiving tokens developed by this agreement will have the ability to confirm the material of the Genesis agreement and verify that any transfer of ownership in the history of the token gotten has complied with the guidelines set out therein.So what can we do with RGB in practice today? Firstly, it makes it possible for the issuance and the transfer of tokenized properties with much better scalability and privacy compared to any existing alternative. On the privacy side, RGB advantages from the reality that all transfer-related data is kept client-side, so a blockchain observer can not extract any info about the users financial activities (it is not even possible to differentiate a bitcoin deal consisting of an RGB dedication from a routine one), additionally, the receiver shares with the sender only blinded UTXO (i. e. the hash of the concatenation between the UTXO in which she want to receive the properties and a random number) rather of the UTXO itself, so it is not possible for the payer to monitor future activities of the receiver. To even more increase the privacy of users, RGB also adopts the bulletproof cryptographic mechanism to conceal the amounts in the history of possession transfers, so that even future owners of assets have an obfuscated view of the monetary behavior of previous holders.In terms of scalability, RGB provides some benefits too. Of all, most of the information is kept off-chain, as the blockchain is only utilized as a dedication layer, decreasing the charges that require to be paid and suggesting that each client only verifies the transfers it is interested in rather of all the activity of a worldwide network. Because an RGB transfer still needs a Bitcoin deal, the charge saving may seem very little, however when you begin presenting deal batching they can rapidly end up being enormous. Indeed, it is possible to transfer all the tokens (or, more usually, “rights”) connected with a UTXO towards an arbitrary quantity of recipients with a single dedication in a single bitcoin deal. Once, lets assume you are a service provider making payments to several users at. With RGB, you can devote in a single Bitcoin deal thousands of transfers to countless users asking for different kinds of assets, making the minimal expense of each single payout absolutely negligible.Another fee-saving mechanism for providers of low worth properties is that in RGB the issuance of an asset does not need paying costs. Because the creation of an issuance contract does not need to be committed on the blockchain, this takes place. An agreement just specifies to which already existing UTXO the recently released assets will be designated to. If you are an artist interested in developing collectible tokens, you can issue as lots of as you desire for complimentary and then only pay the bitcoin transaction fee when a buyer reveals up and demands the token to be appointed to their UTXO.Furthermore, since RGB is constructed on top of bitcoin deals, it is also compatible with the Lightning Network. While it is not yet implemented at the time of composing, it will be possible to develop asset-specific Lightning channels and path payments through them, similar to how it deals with normal Lightning transactions.ConclusionRGB is a cutting-edge development that opens up to new usage cases utilizing an entirely brand-new paradigm, however which tools are readily available to use it? You need to straight attempt out the RGB node if you desire to experiment with the core of the technology itself. If you wish to construct applications on top of RGB without needing to deep dive into the intricacy of the procedure, you can use the rgb-lib library, which provides a basic user interface for designers. If you simply wish to try to provide and transfer assets, you can play with Iris Wallet for Android, whose code is also open source on GitHub. If you just want to discover more about RGB you can check out this list of resources.This is a visitor post by Federico Tenga. Opinions expressed are completely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Rather of publishing the issuance contract openly on a global journal and using that journal to track all future transfers of ownership, it could merely issue the shares independently and pass to the buyers the right to further transfer them. We might carry out a guideline that every transfer of ownership need to be devoted on a predefined spot of a well-known paper (e.g. put the hash of the transfer of ownership in the upper-right corner of the very first page of the New York Times). The link in between a possession and a bitcoin UTXO can happen either in the agreement that issues the possession or in a subsequent transfer of ownership, each time making the target UTXO the controller of the transferred asset. Anyone running a Bitcoin node can independently confirm the commitments and neither the miners nor any other entity are able to interfere or censor with the possession transfer in any way.Since on the Bitcoin blockchain we just release a commitment of an ownership transfer, not the material of the transfer itself, the seller needs a dedicated communication channel to provide the buyer with all the proofs that the ownership transfer is legitimate. Each client getting tokens produced by this agreement will be able to validate the material of the Genesis agreement and confirm that any transfer of ownership in the history of the token gotten has complied with the rules set out therein.So what can we do with RGB in practice today?

Leave a Reply

Your email address will not be published. Required fields are marked *