RGB Magic: Client Contracts on Bitcoin

22-11-29 22:00

Read this article in 16 Minutes

AI summary

View the summary

Original title: "RGB Magic: Client Contracts on Bitcoin"

Original author: Federico Tenga

"Smart Contracts ’ The term has been around longer than blockchain and bitcoin. It first appeared in a 1994 article by Nick Szabo, which defined a smart contract as a "computerized transaction protocol that enforces the terms of the contract." While by definition Bitcoin has supported smart contracts from the beginning thanks to its scripting capabilities, the term became popular because of supporters of Ethereum who tweaked the original definition of smart contracts to become "Code that can be executed redundantly by all nodes of a global consensus network".

While delegating the execution of code to a global consensus network has its advantages (e.g. ease of deploying unowed contracts; an example of such a contract is a popular automated market maker (AMM)), but such a design also has a major flaw: lack of scalability (and privacy). If every node in the network has to redundantly run the same piece of code, the amount of code that can run can only be kept low, or it will unduly increase the cost of running a node (thus hindering decentralization).

So, can we design a system where the terms of the contract are enforced and verified only by the participating parties, rather than by all network members? ? Let us consider the example of a company wishing to issue stock. Instead of placing the issuance contract publicly on a global ledger and using this ledger to track the future transfer of ownership of these shares, I can issue the shares directly and privately and pass on the rights to further transfers to the buyer. The right to transfer ownership can then be passed to each new owner, as if amending the original distribution contract. In this way, each owner can independently verify that the shares they received are genuine by reading the original contract and verifying that all actions to transfer the shares followed the rules in the contract.

This is nothing new, it was the way people transferred property before government registries became popular. For example, in the UK, transfers of property titles were not registered until the 1990s. In other words, 15% of the land in England and Wales is still unregistered. If you're buying an unregistered piece of land, instead of going to the registry to verify that the seller is the true owner, you're verifying that the chain of ownership has passed for at least 15 years (long enough to assume the seller has sufficient title). In doing so, you need to ensure that each transfer of title is properly executed and that any mortgages used for previous transactions have been paid off. The advantage of this model is that it increases the privacy of ownership and you don't have to depend on the maintainers of the government land registry. On the other hand, for the buyer, it makes the job of verifying the seller's title much, much more complicated.

- Image source: Confirmation of Unregistered Immovable Property Title -

So, how to optimize the transfer of this unregistered property? First, make it electronic. Buying and selling would be much quicker and cheaper if the entire history of the transfer of ownership was verified by computer-runable code according to the rules of the original contract.

Secondly, in order to prevent the seller from selling more than one house, a release certification system must be implemented. For example, we could implement a rule that every transfer of ownership must be published in a specific place in a well-known newspaper (for example: put the hash of the ownership transfer operation in the upper right corner of the front page of the New York Times). Because you can't repost the same hash value in the same place, naturally you can't spend it twice. However, there is a downside to using the famous big newspapers:

For verification, you have to buy a big bundle of newspapers. It's not very practical. Every contract needs an exclusive place in the newspaper. This is not convenient for scaling up throughput. Newspaper editors can easily censor you, and even place random hashes in your place to simulate double spending, making potential buyers think your asset has been sold, thereby preventing them from buying your asset. You have to trust the editor of the newspaper.

For these reasons, we need to find a better place to publish proof of ownership transfer. So, where better than the Bitcoin blockchain — an established trusted public ledger with strong incentives to remain censorship-resistant and decentralized?

If we use bitcoin, we should not use the fixed position of the block (such as the first transaction in the block, which is the coinbase transaction) as the release ownership A place to shift commitments, because, like the editors of the New York Times (who can dictate the content of the paper), miners can manipulate it. A better approach is to place a commitment in a predefined Bitcoin transaction, more specifically, a transaction initiated with a UTXO that associates ownership of an issued asset. The link between an asset and a Bitcoin UTXO can be established either through the contract that issued the asset, or in the subsequent transfer of ownership - each transfer can designate a UTXO as the container for the transferred asset. In doing so, we clearly define where the obligation to transfer ownership should be placed (i.e., in a Bitcoin transaction originating from a particular UTXO). Anyone running a Bitcoin node can independently verify this commitment, and no miners or other entities can censor or block this transfer of assets.

transfer of ownership of utxo

Because on the Bitcoin blockchain we only publish ownership The commitment to transfer does not include the transferred content itself, so the seller needs a dedicated information channel to provide the buyer with all the proofs to prove the authenticity of its property rights. This can be done in many ways, even printing out the proof and sending it with a carrier pigeon is a bit impractical, but it does the job. However, the best option to avoid censorship and privacy degradation is to establish a direct peer-to-peer encrypted channel; it also has the advantage of being easy to integrate with proof-of-proof software over carrier pigeons.

The above-mentioned contract and ownership transfer mode based on client verification is exactly what the RGB protocol achieves. With RGB, you can create a set of contracts that define rights to assets, assign assets to one or more UTXOs, and specify how ownership of those assets can be transferred. Contracts can be created starting from a set of templates (called a "schema"), and the creator of the contract only needs to adjust parameters and ownership rights, just like traditional legal contracts do. Currently, the RGB protocol has two types of schemes: one is used to issue homogeneous Token (RGB20), and the other is used to issue collectibles (RGB21); but in the future, people can avoid trust without changing the protocol layer Develop more solutions.

To give a more realistic example, the issuer of a homogeneous asset (such as company stock, stable currency, etc.) can use the RGB20 template to create One defines how many to issue Token , the name of the asset and a contract that carries additional metadata. It can then define which Bitcoin UTXOs are entitled to transfer the created Token ownership, and assign other rights to other UTXOs (such as the right to issue more and rename assets). Each received by this contract created Token Clients can verify the content of the founding contract and verify the received Token Every ownership transfer in history obeyed the rules of the founding contract.

So, what can we do with RGB today? First and foremost, it can be used to issue and transfer Token assets that are more scalable and more private than any other solution today. In terms of privacy, RGB benefits from the fact that all transfer-related data is stored on the client side, and observers of the blockchain cannot extract any information about the user's financial activities from the blockchain (even unable to distinguish the commitments that contain RGB commitments). transactions and ordinary Bitcoin transactions); in addition, the receiver of the asset can only share the blinded UXTO with the sender (that is, the hash value of the UTXO that TA hopes to use to undertake the asset after splicing a random number), instead of the UTXO itself, so the transferor cannot monitor the recipient's future financial activities. In order to further improve the privacy of users, RGB also uses the bulletproof cryptography mechanism to hide the historical asset transfer amount, so that future asset owners can only form a vague understanding of the financial activities of previous owners.

As for scalability, RGB also has advantages. First of all, most of the data is stored off-chain, and the blockchain is only used to save commitments, which reduces the need to pay handling fees, and also means that each client only verifies the transfer history related to itself, while There is no need to verify all activity of a global network. Because RGB transfers still need to initiate Bitcoin transactions, the savings in handling fees seem small, but when you introduce transaction batch processing technology, this part of the savings will quickly become very considerable. In fact, you can place a commitment in a Bitcoin transaction to put all the Token (more broadly, "rights") to any number of recipients. Suppose you are a service provider that needs to pay multiple customers at the same time; with RGB, you can commit thousands of transfers to thousands of customers requesting different assets in a single Bitcoin transaction, allowing each The marginal cost paid becomes negligible.

Another fee-saving mechanism available to issuers of low-value assets is that in RGB there is no fee to issue assets. because creating a Token Issue contracts do not need to be committed on the blockchain. A contract simply defines which existing UTXOs are to be allocated to newly issued assets. So if you're an artist looking to create some collections Token , you can issue any number of free Token , only if the buyer shows up and requests the Token Bitcoin fees are only payable when transferring to their UTXO.

Furthermore, because RGB is built on Bitcoin transactions, it is also compatible with the Lightning Network. While not yet implemented at the time of writing, it is possible to create asset-specific Lightning channels and routing systems, similar to how normal Lightning transactions work.

Conclusion

RGB It is a breakthrough innovation that uses a new paradigm to open up new application scenarios. But what tools do we have available today? If you want to experiment with the core of this technique, you should try the RGB node directly. If you want to develop applications on RGB and don't want to dive into the complexity of the protocol, you can use the rgb-lib library, which provides a simple interface for developers. If you want to try issuing and transferring assets, you can try Iris Wallet (Android), the code of this wallet is also open source. If you want to learn RGB, you can check out this resource list .