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

Author: Shew, geek web3

Editor: Faust, geek web3

**Abstract:****·**The RGB++ asset protocol proposed by the CKB team proposes the idea of **“isomorphic binding”. Its essence is to combine CKB with Cardano, Fuel and other blockchains based on the UTXO programming model. As a function 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. They can hand over the work of verifying asset validity 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 the 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. It has considerable UTXO programmability, allowing developers to write unlocking scripts;

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

4. Can support running 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, CKB is inferior to The two are more suitable as function expansion layers of isomorphically bound Bitcoin asset protocols.

Text: In RGB++Protocol LightPaper, Nervos CKB co-founder Cipher 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 has summarized a series of blockchains that support programmable UTXO in “From BTC to Sui, ADA and Nervos: UTXO Model and Related Extensions”. This article will further explore whether these blockchains can adapt to the same Structure 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 on the Bitcoin chain certain RGB assets are bound to. You have this UTXO, the RGB assets bound to it are also at your disposal.

The RGB protocol and asset protocols such as 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.

But the 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 such an idea: before each transfer takes effect, the recipient first asks the sender to show the entire historical record of the asset, such as who issued these assets from the creation stage to the present, who passed through the assets in the middle, and whether each asset transfer between these people does not violate accounting standards (one person adds, one person subtracts).

In this way, you can know whether the other party gives you “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, it corresponds to the rational person game hypothesis. As long as If the parties concerned are rational and there is no problem with the client software, it can be guaranteed that the asset transfer in question 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.

Since there is no consensus among RGB clients, the release of the RGB asset contract cannot be “extremely reliable” propagated to all nodes. Contract publishers and users simply learn the details of the RGB asset contract spontaneously through any form such as email or Twitter. , 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. Based on the asset source information (historical records) provided by the other party, you can confirm whether there is any problem with the asset source of the other party (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.

In addition, 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 the other party to help store it (note that it is encrypted data, opposite Don’t know the clear 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.

However, 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 if someone wants to transfer money to you, they have to send you the transaction data to check and get your receipt? Can the transfer process be completed only after receiving the message? (The flow chart can be seen in the previous article)

Secondly, most 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, users in the RGB protocol must run the client For self-verification, if you accidentally receive an asset that has changed hands for tens of thousands of people, you will even need to verify the record of tens of thousands of times the asset has changed hands. Obviously, letting users solve everything by themselves is not conducive to the promotion and adoption of the product itself.

For the above problems, 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 should be optimistic and trust that the POW public chain of CKB is reliable; if some people have higher pursuit of security and privacy, such as large investors with large amounts of assets, they can also fall back to the original RGB mode. What should be emphasized here is that RGB++ and the original RGB protocol are theoretically compatible with each other, and they are not mutually exclusive.

In the previous article “From RGB to RGB++: How CKB empowers the Bitcoin Ecological Asset Protocol”, we 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. Cell, 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, users are not required 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 that CKB acts as a historical data storage layer here.

To put it simply, isomorphic binding is not only applicable to RGB, but also to various asset protocols with UTXO characteristics such as Runes and Atomic. It stores the asset status, historical data and corresponding smart contracts locally on the user client. All are transferred to UTXO public chains such as CKB or Cardano for storage and hosting. The above-mentioned UTXO-type asset protocol can use the UTXO model of CKB or Cardano as a “container” to display the shape and status of the asset through the container, making it easier to cooperate with smart contracts and other scenarios.

Moreover, under the isomorphic binding protocol, users can directly use Bitcoin accounts to operate their own RGB asset containers on UTXO chains such as CKB without cross-chain. They only need to use the UTXO characteristics of Cell to set the unlocking conditions of the Cell container. It just needs 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 to the RGB asset transaction trust the security of CKB, they do not even need to frequently publish Commitments on the Bitcoin chain. They can send a Commitment to the Bitcoin chain after many RGB transfers are made. This is called “transaction folding” ” function can reduce the cost of use.

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 In the 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.

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 solution;
2. It 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 is a Bitcoin-related bridge or light node;

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.

At present, 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, and other UTXO-based What about 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 predicate;

Input Contract: UTXO used for contract calls, which contains data such as the state root of the contract and contract assets;

Input Message: UTXO used to transmit information, mainly including fields such as information recipient;

When the user spends the UTXO the following output will be produced:

Output Coin: Used for standard asset transfers;

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

Output Contract Created: A special kind of UTXO, which is the output generated when creating a contract. It 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 will increase 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 in 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 with CKB, eUTXO in Cardano contains the following structures:

**:**Smart contract, used to verify whether UTXO can be unlocked and perform state transition;

Redeemers: Data provided by users for unlocking UTXO, usually signature data, similar to Bitcoin’s Witness;

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

Transaction Context: UTXO transaction context data, such as the 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. 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 auction 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. Of course, 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 binding 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, and 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. Support the operation of 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.