RGB++ and isomorphic binding: How CKB, Cardano and Fuel empower the Bitcoin ecosystem

Forward the Original Title ‘RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态’

Summary:· The RGB++ asset protocol proposed by the CKB team proposedThe essence of the idea of “isomorphic binding” is to use CKB, Cardano, Fuel and other blockchains based on the UTXO programming model as a functional expansion layer that carries RGB asset “containers”.This isomorphic binding is also applicable to Bitcoin ecological asset protocols with UTXO characteristics such as Atomical and Runes, making it easy to build an off-chain smart contract layer for Bitcoin.

· In the RGB++ protocol, users do not have to run the client to personally verify transaction data, and can hand over tasks such as asset validity verification and data storage to UTXO chains such as CKB and Cardanao.As long as you are “optimistic” and believe that the security of the above public chains is relatively reliable, there is no need to verify it yourself;

· The RGB++ protocol supports users to switch back to client verification mode. At this time, you can still use CKB as a data storage/DA layer without having to keep the data yourself. The RGB++ protocol does not require cross-chain assets, and can operate assets on the CKB chain through Bitcoin accounts, and can reduce the frequency of issuing Commitments to the Bitcoin chain, which is also conducive to supporting Defi scenarios;

· If it is under the EVM contract system, many features of RGB++ are not easy to support.Taken together, a public chain/function expansion layer suitable for realizing isomorphic binding should have the following characteristics:

1. Use UTXO model or similar state storage scheme;

2. Has considerable UTXO programmability, allowing developers to write unlocking scripts;

3. There is a UTXO-related state space that can store asset status;

4. It can support the operation of Bitcoin light nodes through smart contracts or other means;

· In addition to CKB, Cardano and Fuel can also support isomorphic binding.However, the latter two may have some baggage in terms of smart contract language and contract design details. At present, it seems that CKB is more suitable than the latter two as a function expansion layer for isomorphically bound Bitcoin asset protocols.

text:existRGB++Protocol LightPaperIn 2017, Cipher, co-founder of Nervos CKB, proposed the product idea of ​​isomorphic binding for the first time. Compared with other Bitcoin Layer 2 solutions, isomorphic binding can be better compatible with asset protocols such as RGB, Runes, and Atomical, and can avoid factors such as cross-chain assets that bring additional security burdens.

To put it simply, isomorphic binding uses UTXO on the CKB and Cardano chains as “containers” to express UTXO assets such as RGB, thereby adding programmability and more complex scenarios. Previously, Geek web3 had appeared in “From BTC to Sui, ADA and Nervos: UTXO model and related extensions》Having summarized a series of blockchains that support programmable UTXO, this article will further explore whether these blockchains can adapt to the isomorphic binding scheme.

RGB++ and isomorphic binding

Before analyzing the compatibility of different UTXO chains with isomorphic binding, we must first introduce the principle of isomorphic binding. Isomorphic binding is a concept proposed by the CKB team in the RGB++ protocol, so here we use the RGB++ workflow to introduce what CKB-based isomorphic binding is.

Before introducing the RGB++ protocol, let us briefly understand the RGB protocol.RGB is an asset protocol/P2P network running under the Bitcoin chain, a bit like the Lightning Network. In addition, RGB is also a parasitic asset protocol based on Bitcoin UTXO.The so-called parasitism means that the RGB client will declare under the Bitcoin chain which UTXO certain RGB assets are bound to on the Bitcoin chain. Once you own this UTXO, the RGB assets bound to it are also at your disposal.

Asset protocols such as the RGB protocol and ERC-20 operate in very different ways. The ERC-20 contract on Ethereum records the asset status of all users, and the Ethereum node client will synchronize and verify all transfer information, and record the status updates after the transfer in the asset contract. This has actually been known to people for a long time, and it is nothing more than relying on the consensus process of Ethereum to ensure that the status changes of assets are smooth.Since the consensus of Ethereum nodes is very reliable, users can default to the asset custody platform based on ERC-20 contracts as “no problem” even if they do not run the client.

butThe RGB protocol is very strange. In order to enhance privacy, it simply deletes the node/client consensus, which is a conventional thing in the blockchain world.Users have to run the RGB client themselves and only receive and store “asset data related to themselves”. They cannot see what others have done. Unlike Ethereum and ERC-20, there are all visible transfer records on the chain.

In this case, if someone transfers some RGB assets to you, you don’t know in advance how the money was created and who it changed hands from.If the person on the other side declares an asset out of thin air and then transfers part of it to you, how do you deal with this evil scenario of counterfeiting currency?

The RGB protocol adopts this idea:Before each transfer takes effect, the recipient first asks the sender to present the entire history of the asset.For example, from the creation stage to the present, who issued these assets, who passed through them, and whether every asset transfer that occurs between these people does not violate accounting standards (one person adds, one person subtracts).

In this way, you can know whether the money given to you by the other party is “questionable money”, so the essence of RGB is to let the parties to the transaction run the client for verification. Based on the client verification mode,Corresponding to the rational person game assumption, as long as the parties involved are rational and the client software is OK, it can be guaranteed that the problematic asset transfer will not take effect or be recognized by others.

It is worth noting that the RGB protocol will compress the transaction data under the Bitcoin chain into a Commitment (essentially a merkle root) and upload it to the Bitcoin chain. This will allow the transfer records under the chain to be directly connected to the Bitcoin main network. Make a connection.

(RGB protocol interaction flow chart)

Since there is no consensus among RGB clients, the release of the RGB asset contract cannot be propagated to all nodes “extremely reliably”.Contract publishers and users simply learn the details of the RGB asset contract spontaneously through email or Twitter, and the form is very casual.

The figure below shows a malicious RGB asset transfer scenario. As an RGB user, we need to store the smart contract corresponding to the RGB asset locally on our client.When others transfer money to us, we can know whether the current transfer violates the rules defined in the contract based on the content of the locally stored asset contract.According to the asset source information (historical record) provided on the opposite side,You can confirm whether there is any problem with the source of the other party’s assets (whether it was declared out of thin air).

Reviewing the above process, it is not difficult to see that the data received and stored by different RGB clients are often independent, and you often do not know what assets others have and how much they are. In turn, others basically don’t know your asset status.

This is a typical data island, that is, the data stored by everyone is inconsistent. Although it can theoretically improve privacy, it also brings a lot of trouble.You must maintain the RGB asset data locally on your client. Once this data is lost, it will cause serious consequences (the asset will be unavailable). But in fact, as long as you maintain local data well, the RGB protocol can bring you security that is basically equivalent to the Bitcoin mainnet.

Also,The Bifrost protocol used for communication between RGB clients will assist users in p2p communication with other clients. They can encrypt their asset data and spread it to other nodes, and ask them to help store it.(Note that this is encrypted data, the other party does not know the plain text). As long as you don’t lose the key, when the local data is lost, you can restore the asset data you originally owned through other nodes in the network.

But the shortcomings of the original RGB protocol are still obvious.First, each transaction requires multiple communications between the two parties. The receiving party must first verify the source of the sender’s assets, and then send a receipt to approve the sender’s transfer request. During this process, at least three messages must be passed between the two parties. This kind of “interactive transfer” is seriously inconsistent with the “non-interactive transfer” that most people are used to.Can you imagine that when someone wants to transfer money to you, they have to send you the transaction data for checking. Can they complete the transfer process only after getting your receipt message?(The flow chart can be seen in the previous article)

Secondly,The vast majority of Defi scenarios require smart contracts with transparent data and verifiable status, but the RGB protocol does not inherently support such scenarios, so it is very unfriendly to Defi; in addition, in the RGB protocol, users must run the client to do their own tasks. verify,If you accidentally receive an asset that has changed hands for tens of thousands of people, you will even have to verify the tens of thousands of times the asset has changed hands. Obviously,let users solve everything by themselves, which is not conducive to the promotion and adoption of the product itself.

Regarding the above issues,RGB++’s solution is to allow users to freely switch between client self-verification mode and third-party hosting mode.Users can leave the burden of data verification and storage, smart contract hosting, etc. to CKB. Of course, users must be optimistic and trust that CKB, the POW public chain, is reliable; if some people have higher pursuit of security and privacy , for example, large investors with large amounts of assets can also fall back to the original RGB mode. What should be emphasized here is thatRGB++ and the original RGB protocol are theoretically compatible with each other.

(RGB++ protocol interaction flow chart [short version])

in previous articles“From RGB to RGB++: How CKB empowers the Bitcoin ecological asset protocol”, we have briefly popularized the “isomorphic binding” of RGB++. Here we will quickly review:

CKB has its own extended UTXO called Cell, which is more programmable than the UTXO on the BTC chain. The “isomorphic binding” is to use the Cell on the CKB chain as a “container” for RGB asset data, and write the key parameters of the RGB asset into the Cell.

Since there is a binding relationship between RGB assets and Bitcoin UTXO, the logical form of the asset has the characteristics of UTXO. andCell, which also has UTXO characteristics, is naturally suitable as a “container” for RGB assets. Whenever an RGB asset transaction occurs, the corresponding Cell container can also show similar characteristics, just like the relationship between entities and shadows.This is the essence of “isomorphic binding”.

For example, if Alice owns 100 RGB tokens and UTXO A on the Bitcoin chain, and has a Cell on the CKB chain, this Cell is marked with “RGB Token Balance: 100”, and the unlocking conditions are related to UTXO A. .

If Alice wants to send 30 tokens to Bob, she can first generate a Commitment. The corresponding statement is: transfer 30 of the RGB tokens associated with UTXO A to Bob, and transfer 70 to other UTXOs she controls.

Afterwards, Alice spends UTXO A on the Bitcoin chain, publishes the above statement, and then initiates a transaction on the CKB chain to consume the Cell container carrying 100 RGB tokens and generate two new containers, one holding 30 tokens ( to Bob), one holds 70 tokens (controlled by Alice).In this process, the task of verifying the validity of Alice’s assets and the validity of the transaction statement is completed by the CKB network nodes through consensus, without Bob’s intervention. CKB now acts as a verification layer and DA layer under the Bitcoin chain.

This is similar to the fact that every time the status of the Ethereum ERC-20 contract changes, the user does not need to run client verification. The principle is similar.The consensus protocol and node network replace client verification.Moreover, everyone’s RGB asset data is stored on the CKB chain, which is globally verifiable, which is conducive to the implementation of Defi scenarios, such as liquidity pools and asset pledge protocols.

This actually introduces an important trust assumption:Users tend to be optimistic that the CKB chain, or the network platform composed of a large number of nodes relying on consensus protocols, is reliable and error-free.If you don’t trust CKB, you can also follow the interactive communication and verification process in the original RGB protocol and run the client yourself.

Of course, if someone wants to run the RGB++ client himself and verify the historical source of other people’s assets, he can directly verify the history related to the RGB asset container Cell on the CKB chain. As long as you run a CKB light node and receive Merkle Proof and CKB block headers, you can be sure that the historical data you receive has not been tampered with by malicious attackers in the network. It can be said,CKB acts as a historical data storage layer here.

simply put,Isomorphic binding is not only applicable to RGB, but also to various asset protocols with UTXO characteristics such as Runes and Atomic., it transfers all the asset status, historical data, and corresponding smart contracts stored locally on the user client to UTXO public chains such as CKB or Cardano for storage and hosting.The above-mentioned UTXO asset protocol can use the UTXO model of CKB or Cardano as a “container” to show the shape and status of the asset.It is convenient to cooperate with scenarios such as smart contracts.

andUnder the isomorphic binding protocol, users can directly use their Bitcoin accounts to operate their RGB asset containers on UTXO chains such as CKB without crossing the chain.You only need to use the UTXO feature of Cell to set the unlocking conditions of the Cell container to be associated with a certain Bitcoin address/Bitcoin UTXO. Since we have already explained the characteristics of Cell in Geekweb3’s previous RGB++ popular science article, we will not go into details here.

If both parties involved in RGB asset transactions can trust the security of CKB, they won’t even need to issue Commitments frequently on the Bitcoin chain.After many RGB transfers are made, a Commitment can be sent to the Bitcoin chain. This is called the “transaction folding” function.Can reduce usage costs.

However, it should be noted that the “container” used in isomorphic binding often requires a public chain that supports the UTXO model, or an infra with similar characteristics in state storage, and the EVM chain is obviously not suitable, and there will be technical implementation problems. Encountered many pitfalls.First of all, as mentioned earlier, RGB++ “can operate asset containers on the CKB chain without cross-chain”, which is basically impossible to implement on the EVM chain; even if it is forcibly implemented, the cost may be very high;

Furthermore, in the RGB++ protocol, many people do not need to run the client or store asset data locally. If the ERC-20 method is used to record everyone’s asset balance in this contract, if someone wants to fall back to the client self-verification mode and proposes to check the source of someone’s assets, at this time he may have to Scanning all transaction records that interact with asset contracts will bring huge pressure.

To put it bluntly,Asset contracts such as ERC-20 couple and store everyone’s asset status. If you want to individually check the asset change history of one of them, it will become difficult.Just like in a public chat room, if you want to know who has sent messages to Wang Gang, you have to flip through the message records in the entire chat room. UTXO is like a one-to-one private chat channel, and it is easy to check the history.

in summary,A public chain/function expansion layer suitable for realizing isomorphic binding should have the following characteristics:

1. Use UTXO model or similar state storage scheme;
2. Has considerable UTXO programmability, allowing developers to write unlocking scripts;
3. There is a UTXO-related state space that can store asset status;
4. There are Bitcoin-related bridges or light nodes;

Of course, we also hope that the public chain used for isomorphic binding has strong security. On the other hand, we also hope that the UTXO unlocking conditions on the public chain should be programmable, so that users can Directly use BTC’s signature scheme to unlock your UTXO isomorphically bound on other public chains without changing the signature algorithm.

Currently, the UTXO locking script on CKB is programmable, and the official is also compatible with the signature schemes of different public chains. For isomorphic binding,The CKB network basically meets the above characteristics. What about other UTXO-based public chains? We have conducted a preliminary inspection of Fuel and Cardano and believe that they can theoretically support isomorphic binding.

Fuel: Ethereum OP Rollup based on UTXO

Fuel is an Ethereum OP Rollup based on UTXO, and is a pioneer in introducing the concept of fraud proof into the Ethereum Layer 2 ecosystem. For normal UTXO function support, Fuel is basically consistent with BTC.

Fuel divides its internal UTXO into the following three categories:

Input Coin：Standard UTXO, used to represent user assets, has a native time lock, and allows users to write unlocking script predicates;

Input Contract：The UTXO used for contract calls contains data such as the state root of the contract and contract assets;

Input Message：UTXO used to transmit information mainly contains fields such as information recipient;

When a user spends a UTXO, the following output is produced:

Output Coin：For standard asset transfers;

Output Contract : The output generated by contract interaction internally contains the state root after contract interaction;

Output Contract Created : A special UTXO is the output generated when creating a contract, which contains the ID and state root of the contract;

Unlike CKB’s Cell, which contains all contract states internally, Fuel’s UTXO does not actually carry all transaction-related contract states. Fuel only carries the contract’s state root Stateroot in UTXO, which is the root of the state tree. The complete state of the contract is stored inside Fuel’s state library and is owned by the smart contract.

It is worth mentioning that,Regarding the status processing of smart contracts, the Fuel contract and the solidity contract are ideologically consistent and even relatively close in programming form.The figure below shows a counter contract written in Fuel’s Sway language. The contract contains a counter. When the user calls the increment_counter function, the counter stored in the contract is incremented by 1.

We can see that the writing logic of the Sway contract is similar to that of a general Solidity contract. We first give the ABI of the contract, then the state variables of the contract, and then the specific implementation of the contract. All code writing processes do not involve Fuel’s UTXO system.

Therefore, Fuel’s contract programming experience is different from UTXO programming languages ​​such as CKB and Cardanao. Fuel provides an experience closer to EVM smart contract programming and development. Developers can also use Sway language to construct unlocking scripts to implement special signature algorithm verification logic or complex multi-signature unlocking logic.

It is basically feasible to implement isomorphic binding within Fuel, but there are still the following problems:

The sway language used by Fuel is closer to the EVM chain in terms of smart contract design than to BTC or CKB and Cardano. Issuers of UTXO assets such as RGB and Atomics need to specifically construct a smart contract on Fuel. CKB and other chains use another one, which is quite complicated.

Cardano: eUTXO public chain based on POS

Cardaon is another blockchain that uses the UTXO model, but unlike Fuel, it is a Layer 1 public chain. Cardano uses eUTXO (extended UTXO) to refer to the UTXO programming model in its system. Compared to CKB,eUTXO in Cardano contains the following structures:

Script: Smart contracts are used to verify whether UTXO can be unlocked and perform state transitions;

Redeemers: The data provided by users for unlocking UTXO is generally signature data, similar to Bitcoin’s Witness;

Datum: The state space of smart contracts can store data such as asset status;

Transaction Context: Contextual data for UTXO transactions, such as input parameters and results of the transaction(The transaction calculation process of the UTXO chain is performed directly off-chain, and the calculation results are submitted to the chain for verification. If they pass the verification, the transaction results are uploaded to the chain)

Developers can use the PlutusCore language to program UTXO on the Cardano chain. Similar to CKB, developers can write unlocking scripts and some functions for status updates.

We introduce Cardano’s UTXO programming model with a UTXO-based auction process. Suppose we need to implement an asset auction DAPP that requires users to give bids before the auction ends. Specifically, the user consumes his or her own UTXO, contracts UTXO with this auction, and then generates a new UTXO. When someone gives a higher bid, in addition to generating a new auction contract UTXO, a refund UTXO for the previous person will also be generated. The specific process is as follows:

To implement the above auction process, some states need to be stored in the UTXO of the auction smart contract, such as the highest price of the current auction and the person who made the bid. The figure below shows the status statement inside PlutusCore. We can see that bBidder and bAmount display the auction bid and the wallet address that gave the bid. The Auction Params contain the basic information of the auction.

When a user spends this UTXO, we can update the state within the contract. The figure below shows some specific status updates and business logic within the auction contract. For example, the logic of verifying user bids and verifying whether the current auction is still in progress. certainly,Since PlutusCore is a Haskell programming language, which is a purely functional programming language, most developers may not be able to directly understand its meaning.

It is feasible to construct isomorphic bindings on Cardano,We can use Datum to store asset status and write specific scripts to be compatible with Bitcoin-related signature algorithms.But the serious problem is that most programmers may not be able to adapt to using PlutusCore for contract programming.Moreover, its programming environment is difficult to set up and is not friendly to developers.

Summarize

Isomorphic binding requires the chain to have the following properties:

1. Use UTXO model
2. Has considerable UTXO programmability, allowing developers to write unlocking scripts
3. There is a UTXO-related state space that can store asset status
4. It can support running Bitcoin light nodes through smart contracts or other means.

Due to the particularity of its smart contract programming ideas, Fuel is compatible with isomorphic binding, but it still brings some baggage; while Cardaon uses the Haskell programming language for contract programming, which makes it difficult for most developers to get started quickly. Based on the above reasons, CKB, which adopts the RISC-V instruction set and is more balanced in the characteristics of UTXO programming, may be a function expansion layer more suitable for isomorphic binding.

Disclaimer：

1. This article is reprinted from [极客 Web3]. Forward the Original Title‘RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态’.All copyrights belong to the original author [Shew]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.