RGB Magic Client Agreements About Bitcoin – Crypto
This is Federico Tenga, long-term contributor to Bitcoin projects, editorial editor with experience as a start-up founder, consultant and educator.
The term “smart contracts” predates the invention of the blockchain and Bitcoin itself. It is first mentioned in a 1994 article by Nick Szabó, who defines smart contracts as “a computer transaction protocol that executes the terms of the contract”. While according to this definition, Bitcoin supported smart contracts from the very first block thanks to its scripting language, the term was popularized only later by the promoters of Ethereum, who changed the original definition to mean that “every node in the global consensus executes code redundantly. network”
While delegating code execution to a global consensus network has advantages (e.g. easy to deploy non-binding contracts such as popular automated market makers), this design has a major flaw: lack of scalability (and privacy). If every node in the network must run the same code redundantly, the amount of code that can actually be executed without excessively increasing the cost of running a node (and thereby preserving decentralization) remains scarce, meaning that only a small number of contracts can be executed. implemented.
But what if we could create a system where the terms of the contract are enforced and enforced only by the parties involved, rather than by all members of the network? Consider the example of a company that wants to issue shares. Instead of publishing the issuance agreement publicly on a global ledger and using that ledger to track all future transfers of ownership, you would simply issue the shares privately and transfer the right to further transfers to the buyers. The right to transfer ownership can then be transferred to each new owner as if it were an amendment to the original issue contract. Thus, each owner can independently verify the authenticity of the shares they receive by reading the original contract and checking whether the history of amendments transferring the shares complies with the rules laid down in the original contract.
This isn’t really new, it’s actually the same mechanism that was used to transfer ownership before public records became popular. In the UK, for example, until the 1990s it was not mandatory to register a property when transferring ownership. This means that even today in England and Wales over 15% are unregistered. If you are buying an unregistered property, instead of checking the register to see if the seller is the real owner, you must prove an unbroken chain of ownership going back at least 15 years (this period is considered long enough to assume that the seller has sufficient ownership of the property) . In doing so, you need to make sure that the transfer of ownership has been done properly and that the mortgages used for previous transactions have been paid in full. This model has the advantage of better privacy over ownership and not having to rely on a public property registry operator. On the other hand, it makes it much more complicated for the buyer to verify the seller’s ownership.
How can the transfer of unregistered properties be improved? First, by making it a digitized process. If there is code that can be run on a computer to check that each history of transfer of ownership conforms to the original contract rules, then buying and selling becomes much faster and cheaper.
Second, in order to avoid the seller spending his funds twice, a system of proof of publication should be introduced. For example, we could introduce a rule that all ownership transfers must be made in a predetermined location of a known newspaper (eg put the ownership transfer hash Times in the upper right corner of the front page of the New York paper). Since you cannot put the hash of the transfer in the same place twice, this prevents double spending. However, using a famous newspaper for this purpose has some disadvantages:
- You need to buy a lot of newspapers for the verification process. Not very practical.
- Each contract needs a separate place in the newspaper. Not very scalable.
- A newspaper editor can easily censor, or worse, simulate double-spending by putting a random hash in the slot, which can trick a potential buyer of the device into thinking it’s already sold and discourage them from buying it. Not too distrustful.
For these reasons, a better place should be found to publish proofs of transfer of ownership. And what better solution than the Bitcoin blockchain, an established, trusted public ledger with strong incentives for censorship-resistant and decentralized preservation?
If we use Bitcoin, don’t specify a fixed place in the block where the obligation to transfer ownership must take place (e.g. at the first transaction) because, just like the editor of the New York Times, the miner can screw it up. A better approach is to place the commitment in a pre-defined Bitcoin transaction, specifically a transaction that originates from an unspent transaction output (UTXO) associated with ownership of the asset to be issued. The link between the asset and the bitcoin UTXO can be established either in the contract issuing the asset or in a subsequent transfer of ownership, each time the target UTXO becomes the controller of the transferred asset. In this way, we clearly defined where the obligation to transfer ownership should be (ie in a Bitcoin transaction from a given UTXO). Anyone using a Bitcoin node can independently verify commitments, and neither miners nor any other entity can censor or interfere with asset transfers in any way.
Since we only publish the commitment to transfer ownership on the Bitcoin blockchain, not the content of the transfer itself, the seller needs a dedicated communication channel to ensure that the buyer receives all proof of the validity of the ownership transfer. This can be done in a number of ways, including printing proofs and shipping them by carrier pigeon, which, while somewhat impractical, would get the job done. But the best solution to avoid censorship and privacy violations is to create a direct peer-to-peer encrypted communication, which has the advantage over pigeons that it can be easily integrated with software that verifies the credentials received from the partner.
This model, which has just been described, is exactly what was implemented with the RGB protocol for client-side validated contracts and ownership transfers. RGB allows you to create a contract that defines rights, assigns them to one or more existing bitcoin UTXOs, and defines how ownership is transferred. The contract can be created based on a template, called a “schema”, in which the creator of the contract modifies only the parameters and ownership rights, as is the case with traditional legal contracts. There are currently two schemes in RGB: one for issuing fungible tokens (RGB20) and one for issuing collectible tokens (RGB21), but in the future more schemes can be developed by anyone without permission, without any changes to the site. at the protocol level.
As a more practical example, an issuer of fungible assets (e.g. corporate shares, stablecoins, etc.) can use the RGB20 schema template and create a contract specifying how many tokens to issue, the name of the asset, and some additional metadata. with this. You can then determine which bitcoin UTXO has the right to transfer ownership of the tokens you create, and assign other UTXOs other rights, such as secondary issuance or renomination of the asset. All clients who receive tokens created under this contract can check the content of the Genesis contract and check whether the transfer of ownership in the history of the received token has complied with the rules contained therein.
So what can we do with RGB in practice? Above all, it enables the issuance and transfer of tokenized assets with better scalability and data protection than any existing alternative. On the privacy side, RGB has the advantage that all data related to the transfer is stored on the client side, so the blockchain monitor cannot extract any information about the user’s financial activities (even a bitcoin transaction containing an RGB commitment cannot be distinguished from a normal one), moreover, the receiver only it shares a blind UTXO (i.e., the UTXO in which you want to receive the assets and the hash of the concatenation between a random number) with the sender, not the UTXO itself, so it is not possible for the payer to monitor the recipient’s future activity. To further increase user privacy, RGB also uses a bulletproof cryptographic mechanism to hide the amounts in the history of asset transfers, so that even future owners of assets have a vague idea of the financial behavior of previous owners.
In terms of scalability, RGB also offers some advantages. First, most of the data is stored off-chain, as the blockchain is only used as a commitment layer, which reduces the fees to be paid and means that each customer only validates the transfers they are interested in, rather than the activity of the entire global network. Since RGB transfer still requires a Bitcoin transaction, the fee savings may seem minimal, but when you start implementing transaction bundling, it can quickly become huge. In fact, it is possible to transfer all the tokens (or more generally, “rights”) associated with a UTXO to any number of recipients with a single commitment in a single bitcoin transaction. Let’s say you’re a service provider that makes payments to multiple users at the same time. With RGB, you can make thousands of transfers with a single Bitcoin transaction to thousands of users requesting different types of assets, so the marginal cost of each payment is completely negligible.
Another fee-saving mechanism for small value asset issuers is that there is no fee to issue an asset in RGB. This is because the creation of the emission contract does not need to be committed on the blockchain. The contract simply specifies to which existing UTXO the newly issued assets will be assigned. So if you’re an artist interested in making 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 asks for the token to be assigned to UTXO.
Furthermore, since RGB is built on 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 device-specific Lightning channels and route payments through them, similar to how normal Lightning transactions work.
RGB is a groundbreaking innovation that opens up new use cases with an entirely new paradigm, but what tools are available to use it? If you want to experiment with the core of the technology itself, you should try the RGB node directly. If you want to build applications on top of RGB without diving deep 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 issue and transfer 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. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Crypto.