In July 2024, CKB officially announced the launch of the RGB++ Layer, marking the transformation of the previously theoretical RGB++ protocol into a fully engineered product, poised to introduce more concrete and practical application scenarios. With the vision of constructing a BTCFi ecosystem across BTC and other UTXO-based public chains such as CKB and Cardano, RGB++ Layer quickly garnered significant attention. In summary, the RGB++ Layer is based on the RGB++ protocol, utilizing homomorphic binding and Leap technology to provide a seamless cross-chain interaction experience for native RGB++ assets or inscriptions/runes across UTXO-based blockchains like BTC, CKB, and Cardano without the need for cross-chain bridges. Leveraging CKB’s Turing-complete smart contract environment, it establishes the necessary conditions for Bitcoin to achieve complex DeFi functions. Moreover, backed by CKB’s comprehensive account abstraction ecosystem, it is compatible with Bitcoin accounts and wallets, offering an excellent user experience for Bitcoin users and paving the way for the widespread adoption of BTCFi. In the following text, let’s delve into the working principles and features of the RGB++ Layer and explore the changes it will bring to the BTCFi ecosystem. Given that its theoretical foundation is built on the RGB++ protocol, we will begin by discussing the protocol itself.

RGB++ Protocol: The Theoretical Foundation of RGB++ Layer

The RGB++ protocol, released in January of this year, fundamentally transforms the validation method from the RGB protocol’s “client-side validation” to on-chain verification on the CKB chain. Essentially, this approach leverages CKB as a decentralized indexer, assigning tasks such as data storage and asset source verification to CKB. This positions CKB as the validation layer and DA layer for the RGB protocol, addressing the UX issues and DeFi support limitations inherent in the original RGB protocol.

Aligning with the concept of “one-time encapsulation,” RGB++ introduces the notion of homomorphic binding, utilizing CKB chain’s extended UTXO—Cells—as data carriers for inscription/rune-like assets. These Cells are then bound to UTXOs on the Bitcoin, Cardano, or Liquid chains, enabling RGB++ assets to inherit the security of these UTXO-based blockchains and preventing double-spending. This “binding to inherit security” approach is analogous to real-world scenarios where a bank account needs to be linked to a phone number and ID for enhanced security.

For instance, suppose Alice wants to transfer some TEST tokens to Bob. She can generate a statement binding the Cell that stores the TEST asset information to Bob’s Bitcoin UTXO. If Bob intends to transfer the TEST tokens to someone else, the bound Bitcoin UTXO must also be transferred. This creates a one-to-one binding relationship between the Cell carrying RGB++ asset data and the Bitcoin UTXO. As long as the Bitcoin UTXO is not double-spent, the bound RGB++ asset will not be double-spent either.

When discussing the RGB++ Layer, it is essentially an engineered implementation of the RGB++ protocol, featuring two main characteristics: isomorphic binding and Leap bridge-free cross-chain. Let’s delve into the technical principles behind isomorphic binding and Leap.

Isomorphic Binding and Leap: BTCFi’s Asset Issuance and Bridge-Free Cross-Chain Layer

To truly grasp the concepts of isomorphic binding and Leap, we first need to briefly explain CKB’s Cell model. Essentially, a Cell is an extended UTXO (Unspent Transaction Output) with several fields, including LockScript, TypeScript, and Data. The LockScript functions similarly to Bitcoin’s locking script and is used for permission verification. TypeScript is akin to smart contract code, while Data is used to store asset data.

To issue RGB++ assets on the CKB blockchain, you first need to create a Cell and populate the relevant fields with the token symbol and contract code. For example, you might set the token symbol to “TEST.” These Cells can then be disassembled and distributed to many users, similar to how Bitcoin UTXOs (Unspent Transaction Outputs) are split and transferred.

Because the structure of Cells is similar to Bitcoin’s UTXO and CKB can support Bitcoin’s signature algorithms, users can manipulate assets on the CKB chain using Bitcoin wallets. If you own a Cell, you can configure the locking script to match the unlocking conditions of Bitcoin UTXOs. This allows you to use Bitcoin private keys to control Cells on the CKB chain. This capability extends to CKB, BTC, and other UTXO-based public chains. For example, you could use a Cardano account to modify asset data on the CKB chain, transferring control of RGB++ assets from a BTC account to a Cardano account without the need for a cross-chain bridge.

This process requires binding RGB++ assets to UTXOs on public chains like Bitcoin, Cardano, and Liquid, much like linking a bank account to a phone number and ID in the real world. RGB++ assets are essentially data that need a storage medium like a database; in this case, CKB Cells act as the database. You can set up permission verification to allow different public chain accounts (BTC, Cardano, etc.) to modify RGB++ asset data on the CKB chain. This is the core principle of isomorphic binding.

Leap and Bridge-Free Cross-Chain

The “Leap” and bridge-free cross-chain features of the RGB++ Layer are based on isomorphic binding. They allow for the “rebinding” of UTXOs associated with RGB++ assets. For instance, if your asset was initially bound to a Bitcoin UTXO, you can rebind it to a UTXO on Cardano, Liquid, Fuel, or other chains. This means you can transfer asset control from a BTC account to a Cardano account, all without the need for a cross-chain bridge.

From a user’s perspective, this is equivalent to cross-chain asset transfer, with CKB acting as both an indexer and a database. However, unlike traditional cross-chain methods, “Leap” only changes the usage permissions of the asset data while the data itself remains stored on the CKB chain. This approach is simpler than the Lock-Mint model and eliminates the dependency on mapping asset contracts. The above explanation is a product overview of isomorphic binding and Leap. Let’s understand their technical implementation through a specific example.

Implementation of Isomorphic Binding

Let’s understand the technical implementation of isomorphic binding. Suppose Alice has 100 TEST tokens, with data stored in Cell#0, bound to UTXO#0 on the Bitcoin chain. Now, Alice wants to transfer 40 TEST tokens to Bob. First, she splits Cell#0 into two new Cells: Cell#1, containing 40 TEST tokens, which is transferred to Bob, and Cell#2, containing 60 TEST tokens, which remains under Alice’s control. In this process, the BTC UTXO#0 bound to Cell#0 is also split into UTXO#1 and UTXO#2, bound to Cell#1 and Cell#2, respectively. When Alice transfers Cell#1 to Bob, she can also transfer BTC UTXO#1 to Bob with a single operation, achieving synchronized transactions on both the CKB and BTC chains.

We can understand isomorphic binding in depth here. In fact, the core meaning of this concept is thatCKB’s Cell, Cardano’s eUTXO and BTC UTXO are all UTXO models, and CKB is compatible with the Bitcoin/Cardano signature algorithm. The decomposition and transfer of UTXO that occurs on the latter two chains can also be synchronized 1:1 to the Cell on the CKB chain. .In this way, when we operate the BTC UTXO bound to the RGB++ asset, the operation results can be synchronized to the Cell on the CKB chain, just like the relationship between the entity and the shadow. In addition, we must also pay attention toThe RGB++ asset is associated with the two entities BTC UTXO and CKB Cell, both of which are components of the RGB++ asset.Both are indispensable.

If we examine the above-mentioned case of Alice transferring money to Bob, the general process is:1. Alice constructs a CKB transaction data locally (not uploading it to the chain yet). This transaction indicates that Cell#0, which records the asset data, will be destroyed, Cell#1 will be generated and given to Bob, and Cell#2 will be kept for herself;2. Alice generates a statement locally, binds Cell#1 to BTC UTXO#1, binds Cell#2 to BTC UTXO#2, and sends both Cell#1 and BTC UTXO#1 to Bob;3. Afterwards, Alice generates a Commitment (similar to a hash) locally, and the corresponding original content contains the statement in step 2 + the CKB transaction data generated in step 1. The Commitment data will then be recorded on the Bitcoin chain;4. Alice initiates a transaction on the Bitcoin chain, destroys UTXO#0, generates UTXO#1 and sends it to Bob, keeps UTXO#2 for herself, and writes Commitment to the Bitcoin chain in the form of OP_Return opcode;5. After step 4 is completed, send the CKB transaction generated in step 1 to the CKB chain.

Some of the more complicated details have been omitted above.In fact, when Alice transfers her RGB++ assets to Bob, she must first perform complex identity verification to prove that she is indeed the owner of Cell#0.The things involved here include: 1. Proving that Cell#0 and BTC UTXO#0 are indeed bound; 2. Alice proves that she is the actual controller of Cell#0 and BTC UTXO#0. Be careful,Cells and Bitcoin UTXOs written with RGB++ asset data can be rewritten simultaneously by Bitcoin accounts. During the entire interaction process, one-click operations can be completed through Bitcoin accounts.The above scenarios are not limited to the isomorphic binding between Bitcoin and CKB, but can be extended to Cardano, Liquid, Litecoin and other broad categories. There is still a lot of room for imagination.

Leap’s implementation principles and support scenarios

We mentioned earlier thatThe Leap function is actually to switch the UTXO bound to the RGB++ asset, such as switching it from Bitcoin to Cardano, and then you can use the Cardano account to control the RGB++ asset.After that, you can also transfer funds on the Cardano chain to split and transfer the UTXO controlling RGB++ assets to more people. In this way, RGB++ assets can be transferred and distributed on multiple UTXO public chains, but the traditional cross-chain bridge Lock-Mint model can be bypassed. In this process, the CKB public chain needs to act like an indexer to witness and process Leap requests. Suppose you want to transfer RGB++ assets bound to BTC to a Cardano account. The core steps are nothing more than:1. Publish a Commitment on the Bitcoin chain, announcing the unbinding of the Cell bound to BTC UTXO;2. Publish a Commitment on the Cardano chain, announcing that the Cell will be bound to Cardano UTXO;3. Change Cell’s locking script to change the Bitcoin UTXO associated with the unlocking conditions to eUTXO on Cardano.

We can notice that during this entire process, the RGB++ asset data is still stored on the CKB chain, but the Bitcoin UTXO associated with the unlocking conditions is changed to eUTXO on the Cardano chain. Of course, the specific execution process is much more complicated than what is mentioned above, so I won’t go into details here. In additionThere is an implicit premise in the leap plan, that is, the CKB public chain serves as a third-party witness, index and DA facility. As a public chain, its credibility far exceeds traditional cross-chain bridge methods such as MPC and multi-signature.In fact, very interesting scenarios can be realized based on the Leap function. For example, we can realize “full chain transactions”. Suppose we build an indexer across Bitcoin, Cardano and CKB, and build a trading platform that allows buyers and sellers to trade RGB++ assets. Buyers can transfer their Bitcoins to sellers and then use their Cardano accounts to receive RGB++ assets. . During this process, the data of the RGB++ asset is still recorded in the Cell, but the Cell will be transferred to the buyer, and then its unlocking permission will be changed from the seller’s Bitcoin UTXO to the buyer’s Cardano eUTXO.

Wrapper

Although the Leap function is perfect for RGB++ assets, there are still some bottlenecks: For Bitcoin and Cardano, RGB++ assets are essentially inscriptions/runes/dyed coins based on the OP_RETURN opcode. These public chain nodes cannot perceive the existence of RGB++ assets, and CKB actually participates in coordination as an indexer. That is to say,For Bitcoin and Cardano, the RGB++ Layer mainly supports the Leap of inscriptions/runes/dyed coins, rather than the cross-chain of native assets such as BTC and ADA.In this regard, RGB++ Layer officially introduced Wrapper, which can be simply understood as a bridge based on fraud proof and over-collateralization. Taking the rBTC wrapper as an example, it bridges BTC to the RGB++ Layer, and a set of smart contracts running on the RGB++ Layer monitor the bridge’s guardians. If a guardian behaves maliciously, their collateral will be slashed. If guardians collude to steal locked BTC, rBTC holders can receive full compensation.

After combining Leap and Wrapper, various assets in the BTCFi ecosystem, such as RGB++ native assets, BRC20, ARC20, runes, etc., can be transferred to other layers or public chains.

The picture below is part of the application process of LeapX. You can see that it supports the interoperability of almost all BTCFi mainstream assets into different ecosystems. And there are corresponding processing procedures for assets with different issuance methods. Some use wrapper, and some use leap.

CKB-VM: BTCFi’s smart contract engine

Above we mainly explained the isomorphic binding and Leap concepts of RGB++ Layer. Let us examine other points below.In traditional BTCFi, due to the lack of smart contract support, only some relatively simple Dapps can be implemented.Some implementation methods have certain risks of centralization, while others are clumsy and inflexible. In order to implement a smart contract layer available on the blockchain,CKB provides CKB-VM for RGB++ Layer. Any programming language that can support RISC-V virtual machine can be used for contract development on RGB++ Layer.Developers can use their preferred tools and languages ​​to achieve efficient and secure smart contract development and deployment under a unified smart contract framework and execution environment. The following is a transfer method of user-defined token UDT in CKB implemented in C language. It can be seen that except for the difference in language, its basic logic is the same as that of general tokens. Since RISC-V has extensive language and compiler support, the requirements for developers to get started with smart contract development are relatively low. We can easily rewrite this logic using JavaScript, Rust, Go, Java and Ruby. Instead of having to learn a certain DSL language to write contracts. Of course, language is only one aspect of programming, and learning specific smart contract frameworks is inevitable.

Native AA ecology: seamlessly connect BTC and RGB++

Finally, let us briefly understand the native AA and account abstraction ecology behind RGB++ Layer. Since the essence of BTCFi is to provide a diverse Defi experience for native Bitcoin assets, whether it is compatible with mainstream Bitcoin wallets will be an important factor to consider for BTCFi peripheral facilities.RGB++ Layer directly reuses CKB’s native AA solution and can be compatible with important UTXO public chains such as BTC and Cardano on both the developer side and the user side.In RGB++ Layer, users can use different signature algorithms for authentication. For example, users can directly manipulate assets on the RGB++ Layer using accounts, wallets or authentication methods such as BTC, Cardano or even WebAuthn. Let’s take the following wallet middleware CCC as an example, which can provide wallets and dApps with the operability of various public chains on CKB. The picture below is the connection window of CCC. We can see that it supports mainstream wallet entrances such as Unisat and Metamask.

Another example is the implementation of WebAuthn, of which CKB ecological wallet JoyID is a typical representative. With JoyID, users can authenticate directly through biometrics such as fingerprint or facial recognition, enabling seamless and highly secure login and identity management. It can be said that the foundation for isomorphic binding and Leap is that RGB++ Layer has a complete native AA solution, which is well compatible with the account standards of other public chains. This feature not only facilitates support for some key scenarios, but also provides UX clears the way.

Summarize

In the above, we have examined the overall picture of RGB++ Layer. It can be used as an important infrastructure for various Memecoins such as inscriptions/runes/dyed coins to realize full-chain interaction scenarios. The smart contract execution environment built by RGB++ Layer based on RiscV can create soil for the complex business logic required by BTCFi. Due to space limitations, this article is only a simple popularization of the core technology of RGB++ Layer, and does not conduct a systematic popularization of many complex details. In the future, we will continue to pay attention to the progress of RGB++ Layer and conduct a more thorough and in-depth analysis of a series of technical solutions related to this project. Please stay tuned!

statement:

1. This article is reproduced from [geek web3], the copyright belongs to the original author [Faust & Misty Moon], if you have any objections to the reprint, please contact the Gate Learn team, and the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.