RGB++ and isomorphism binding: How CKB, Cardano, and Fuel empower BTC

Author: Shew, geek web3

Abstract:

· The RGB++ asset protocol proposed by the CKB team, proposed The idea of ​​"isomorphic binding" is essentially 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. 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 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 implementing isomorphic binding should have the following characteristics:

1. Use UTXO Model or similar state storage solution;

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 through smart contracts or other means. Node;

· In addition to CKB, Cardano and Fuel can also support isomorphic binding.However, the latter two have limitations in smart contract languages ​​and There may be some baggage in 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.

In RGB++Protocol LightPaper, Nervos CKB co-founder Cipher is the first The product idea of ​​isomorphic binding was proposed 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, and then adds programmability and more complexity to them. scene. Previously, Geek web3 had published in "From BTC to Sui, ADA and Nervos: UTXO model and related expansions ” has 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 isomorphic binding determined principle. 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 that runs off 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 own this UTXO, and the RGB assets bound to it are also at your disposal.

The RGB protocol operates completely differently from asset protocols such as ERC-20. 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. Because 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 theRGB protocol is very strange. It is for To enhance privacy, simply delete 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, everything is visible on the chain. Transfer records.

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 opposite declares an asset out of thin air and then transfers part of it to you, how should 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 From the creation stage to the present, who issued these assets, who passed through them, and whether every transfer of assets 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 transaction parties run the client themselves for verification, based on client verification Model,Corresponding to the rational person game assumption, as long as the parties involved are rational and the client software is OK, it can ensure that the problematic asset transfer cannot 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, which makes the transfer records under the chain , directly related to the Bitcoin mainnet.

(RGB protocol interaction flow chart)

Due to the lack of consensus among RGB clients, the release of RGB asset contracts cannot be "extremely reliable" propagated to all nodes. 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 following figure 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 record) provided by the other party, it can be confirmed whether there is any problem with the other party’s asset source (whether it was declared out of thin air).

Reviewing the above process, it is not difficult to see that different RGB The data received and stored by the client is often independent, and you often don't 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 data of RGB assets locally on your client. Once these data are lost, it will cause serious consequences (the assets are 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, It will assist the user in p2p communication with other clients. He can encrypt his asset data and spread it to other nodes, and ask the other party to help store it (note that it is encrypted data, and 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.

However, the shortcomings of the original RGB protocol are still obvious. First, each transaction requires multiple communications between the two parties. The receiver must first verify the source of the sender's assets and then send a receipt. , 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 also have to send you the transaction data for checking, and you get Can the transfer process be completed only after receiving your receipt message? (The flow chart can be seen above)

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, in the RGB protocol, users must run the client for self-verification. If you accidentally receive an asset that changes hands from tens of thousands of people, you even have to verify it. Records of tens of thousands of times this asset has changed hands. Obviously, leavingall things to users to solve 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 switch freely between client self-verification mode and third-party hosting mode. Users can The burden of data verification and storage, smart contract hosting, etc. is left to CKB. Of course, users must be optimistic and trust that CKB, the POW public chain, is reliable; if some people who have higher pursuit of security and privacy, such as mobile phones, 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, and they are not mutually exclusive.

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

In the previous article In "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, so in the asset It has the characteristics of UTXO in logical form. 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". The unlocking conditions are related to UTXO A.

If Alice wants to give 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 herself. Other UTXOs controlled.

Afterwards, Alice spends UTXO A on the Bitcoin chain, issues 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 holds 30 tokens (for Bob) and one holds 70 tokens (controlled by Alice). During 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 Ethereum ERC-20 contract each time Status changes do not require users 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 thatCKB 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 local asset status, historical data, and corresponding smart contracts on the user client are all moved 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", and use the container to show the shape and status of the asset. It is convenient to cooperate with smart contracts and other scenarios.

Andunder the isomorphic binding protocol, users can directly use their Bitcoin accounts to operate their own RGB asset containers on UTXO chains such as CKB without crossing the chain. With the help of Cell's UTXO feature, just set the unlocking condition 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 to the RGB asset transaction trust the security of CKB, they do not even need to frequently Commitment is released on the Bitcoin chain. After many RGB transfers are carried out, a Commitment can be sent to the Bitcoin chain. This is called the "transaction folding" function, which 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 very suitable. Suitable, there will be many pitfalls in technical implementation. First of all, as mentioned earlier, RGB++ "can operate asset containers on the CKB chain without cross-chain" 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 change. It's very difficult. It's like being 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.

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 script;

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 public chain on the UTXO unlocking conditions should be programmable. In this way, users can directly use BTC's signature scheme to unlock their isomorphically bound UTXO 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, theCKB network basically complies with the above. feature, 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, or the concept of fraud proof A pioneer in introducing 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:Used UTXO used to transmit information, mainly includes fields such as information recipient;

When the user spends UTXO, the following output will be generated:

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;

The Cell of CKB contains all the Contract status is different. Fuel's UTXO does not actually carry all transaction-related contract status. 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 thatFor the status processing of smart contracts, the Fuel contract and the solidity contract are ideologically consistent and even relatively close in programming form. The following figure 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 give the state variables of the contract, and then give the specific implementation of the contract. All code writing processes do not involve Fuel's UTXO system.

So, Fuel’s contract programming experience is different from UTXO-type programming such as CKB and Cardanao Language, Fuel provides an experience closer to EVM smart contract programming 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 not suitable for smart contract design On the other hand, the idea is closer to the EVM chain than to BTC or CKB and Cardano. Issuers of UTXO assets such as RGB and Atomics need to construct a smart contract specifically on Fuel and use another one on chains such as CKB. This is quite complex.

Cardano: POS-based eUTXO public chain

Cardano is another blockchain using the UTXO model, but unlike Fuel, it is a Layer1 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 parts of the structure:

Script:  Smart contract, used to verify whether the UTXO Can be unlocked and perform state transitions;

Redeemers:  The data provided by the user for unlocking UTXO, usually 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 of 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. chain)

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

We introduce Cardano’s UTXO programming model with an auction process based on UTXO. 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, you need to auction smart contract UTXO Some status is stored in the memory, 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 the user spends this UTXO, we can update the status 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.

Constructing isomorphic bindings on Cardano has Feasibility,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.

Summary

Isomorphic binding requires the chain to have the following properties:

1. Using 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 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 contracts Programming is 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.