Author: Faust & Wuyue, BTCEden
In July 2024, CKB officially announced the official launch of RGB++ Layer, marking that the previously released RGB++ protocol has completely been transformed from a theoretical implementation to an engineering product, and will introduce more specific and practical application scenarios. With the vision of building a BTCFi ecosystem between BTC and pan-UTXO public chains such as CKB and Cardano, RGB++ Layer quickly became the focus of attention.
In summary, RGB++ Layer is based on the RGB++ protocol, using isomorphic binding and Leap technology to provide a "cross-chain bridge-free" full-chain interactive experience for RGB++ native assets or inscriptions/runes between UTXO-type public chains such as BTC, CKB, and Cardano; Using CKB's Turing-complete smart contract environment, it builds the necessary conditions for Bitcoin to build from asset issuance to the realization of complex DeFi functions.
Because RGB++ Layer is backed by CKB's complete account abstraction ecosystem and is compatible with Bitcoin accounts and wallets, it can create a good experience for Bitcoin users and pave the way for the large-scale adoption of BTCFi.
In the following, let us deeply understand the general working principle and characteristics of RGB++ Layer and look forward to the changes it will bring to the BTCFi ecosystem. Since its theoretical basis is built on the RGB++ protocol, we will start with the protocol itself.
The RGB++ protocol was released in January this year. Its core concept is to replace the "client verification" of the RGB protocol with the form of CKB chain verification. In essence, it regards CKB as a decentralized indexer, and entrusts tasks such as data storage and asset source verification to CKB, which serves as the verification layer and DA layer of the RGB protocol to solve the shortcomings of the RGB protocol in UX and its defects in supporting Defi.
In line with the concept of "one-time packaging", RGB++ introduces the concept of isomorphic binding, using the extended UTXO on the CKB chain - Cell as the data carrier of inscription/rune assets, and then establishing a binding relationship between Cell and UTXO on the Bitcoin/Cardano/Liquid chain, and finally let RGB++ assets inherit the security of UTXO public chains such as Bitcoin to prevent double spending.
This idea of "binding XXX to inherit XXX security" is similar to the binding of mobile phone numbers and ID cards to bank accounts in reality.
For example, if Alice wants to transfer some TEST tokens to BOB, she can generate a statement to bind the Cell storing 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.
In this way, the Cell that carries the RGB++ asset data has a one-to-one binding relationship with the Bitcoin UTXO. As long as the Bitcoin UTXO is not double-spent, the bound RGB++ assets will not be double-spent.
Speaking of the RGB++ Layer, it is actually the product of the engineering implementation of the RGB++ protocol. Its two main features include isomorphic binding and Leap bridgeless cross-chain. Let us take a deeper look at the technical implementation principles of isomorphic binding and Leap.
In order to truly understand the ideas of isomorphic binding and Leap, let's first briefly talk about CKB's Cell model.
Cell is essentially an extended UTXO, with multiple fields such as LockScript, TypeScript, and Data. The function of LockScript is similar to that of Bitcoin's lock script, and is used for permission verification; TypeScript is similar to smart contract code, and Data is used to store asset data.
If you want to issue RGB++ assets on the CKB chain, you must first create a Cell and write the token symbol and contract code in the relevant fields, such as the token symbol is TEST. After that, you can disassemble these Cells and distribute them to many people, just like the splitting and transfer of Bitcoin UTXO.
Since Cell is similar to Bitcoin UTXO in structure, and CKB is compatible with the Bitcoin signature algorithm, users can use Bitcoin wallets to manipulate CKB chain assets. If you own a Cell, you can set the locking script to make the unlocking conditions consistent with the unlocking conditions of Bitcoin UTXO, so that you can use the Bitcoin account private key to manipulate the Cell on the CKB chain.
The above features can also be realized between CKB, BTC and other UTXO public chains. For example, you can also use Cardano accounts to rewrite asset data on the CKB chain, and the control of RGB++ assets can also be transferred from BTC accounts to Cardano accounts without cross-chain bridges. We will explain this topic below.
As we mentioned earlier, RGB++ assets need to be bound to UTXO on public chains such as Bitcoin, Cardano, and Liquid, similar to how bank accounts in reality need to be bound to mobile phone numbers and ID cards; secondly, RGB++ assets themselves are just a bunch of data, which need to have a storage medium such as a database, and the Cell on the CKB chain can serve as its database.
Then we can set up permission verification to allow people to use accounts on different public chains such as BTC and Cardano to rewrite RGB++ asset data on the CKB chain. This is the core purpose of isomorphic binding.
RGB++ Layer proposed "Leap" and bridgeless cross-chain, which are actually based on isomorphic binding technology to "re-bind" the UTXO bound to RGB++ assets. For example, if your assets were previously bound to Bitcoin UTXO, you can now re-bind them to UTXO on Cardano, Liquid, Fuel and other chains, so that the asset control authority can be transferred from the BTC account to the Cardano account.
From the perspective of user perception, this is actually equivalent to asset cross-chain, and CKB plays a role similar to an indexer and database. However, unlike the traditional cross-chain method, "Leap" only changes the usage rights of asset data, and the data itself is still stored on the CKB chain. This method is simpler than the Lock-Mint mode and eliminates the reliance on the mapped asset contract.
The above is just a description of the product effects of isomorphic binding and Leap. Let us understand their technical implementation ideas through specific cases.
Let us understand the technical implementation of isomorphic binding. Suppose Alice has 100 TEST tokens, the data is stored in Cell#0, and it is bound to UTXO#0 on the Bitcoin chain.
Now, Alice wants to transfer 40 TEST tokens to Bob. First, she wants to split Cell#0 into two new Cells, where Cell#1 contains 40 TEST tokens and is transferred to Bob; Cell#2 contains 60 TEST and is still controlled by Alice herself.
In this process, BTC UTXO#0 bound to Cell#0 must also be split into UTXO#1 and UTXO#2, and bound to Cell#1 and Cell#2 respectively. When Alice transfers Cell#1 to Bob, she can transfer BTC UTXO#1 to Bob with one click, and realize synchronous transactions on CKB and BTC chains.
We can deeply understand the isomorphic binding here. In fact, the core meaning of this concept is that CKB's Cell, Cardano's eUTXO and BTC UTXO are all UTXO models, and CKB is compatible with Bitcoin/Cardano signature algorithms. The decomposition and transfer of UTXO on the latter two chains can also be synchronized 1:1 to the Cell on the CKB chain.
In this way, when we operate on the BTC UTXO bound to the RGB++ asset, we can synchronize the operation results to the Cell on the CKB chain, just like the relationship between the entity and the shadow. In addition, we should also note that RGB++ assets are associated with the two entities of BTC UTXO and CKB Cell, both of which are components of RGB++ assets and are indispensable.
If we examine the case of Alice transferring money to Bob mentioned above, the general process is as follows:
1. Alice constructs a CKB transaction data locally (not on 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.After that, Alice generates a Commitment locally (similar to a hash), and the corresponding original content includes the statement in step 2 + the CKB transaction data generated in step 1. The data of the Commitment 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 the Commitment to the Bitcoin chain in the form of OP_Return opcode;
5. After step 4, send the CKB transaction generated in step 1 to the CKB chain.
Some more complicated details are 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. Things involved here include:
1. Prove 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.
Note thatCell and Bitcoin UTXO with RGB++ asset data can be rewritten synchronously by Bitcoin accounts.In the entire interaction process, one-click operation can be completed through Bitcoin accounts.The above scenario is not limited to the isomorphic binding between Bitcoin and CKB, but can be extended to Cardano, Liquid, Litecoin and other broad categories, and there is still a lot of room for imagination.
As we mentioned earlier,Leap function is actually to switch the UTXO bound to RGB++ assets, such as changing it from Bitcoin to Cardano, and then the Cardano account can be used to control RGB++ assets. After that, you can also transfer money on the Cardano chain, splitting the UTXO that controls RGB++ assets and transferring them to more people.
In this way, RGB++ assets can be transferred and distributed on multiple UTXO public chains, but it can bypass the traditional cross-chain bridge Lock-Mint model. In this process, the CKB public chain needs to play a role similar to an indexer to witness and process Leap requests.
Suppose you want to transfer RGB++ assets bound to BTC to a Cardano account, the most core steps are nothing more than:
1. Publish a Commitment on the Bitcoin chain, declaring that the Cell bound to the BTC UTXO will be unbound;
2. Publish a Commitment on the Cardano chain, declaring that the Cell will be bound to the Cardano UTXO;
3. Change the locking script of the Cell, and change the Bitcoin UTXO associated with the unlocking condition to the eUTXO on Cardano.
We can notice that in this whole process, the RGB++ asset data is still stored on the CKB chain, but the Bitcoin UTXO associated with the unlocking condition is changed to the eUTXO on the Cardano chain. Of course, the specific execution process is much more complicated than what is mentioned above, so I will not go into details here.
In addition, there is an implicit premise in the Leap solution, that is, the CKB public chain is a third-party witness, index and DA facility. As a public chain, its credibility is far higher than the MPC and multi-signature methods of traditional cross-chain bridges.
In fact, based on the Leap function, very interesting scenarios can also be realized, such as 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 Bitcoin to sellers and then use their Cardano accounts to receive RGB++ assets.
During this process, the data of RGB++ assets is still recorded in the Cell, but this Cell will be transferred to the buyer, and then its unlocking authority will be changed from the seller's Bitcoin UTXO to the buyer's Cardano eUTXO.
Although the Leap function is perfect for RGB++ assets, there are still some bottlenecks:
For Bitcoin and Cardano, RGB++ assets are essentially inscriptions/runes/colored coins based on the OP_RETURN opcode. These public chain nodes cannot perceive the existence of RGB++ assets, and CKB actually participates in the coordination as an indexer. In other words, for Bitcoin and Cardano, RGB++ Layer mainly supports Leap of inscriptions/runes/colored coins, rather than cross-chain native assets such as BTC and ADA.
In response to this, RGB++ Layer officially introduced Wrapper, which can be simply understood as a bridge based on fraud proof and over-collateralization. Taking rBTC wrapper as an example, it bridges BTC to RGB++ Layer, and a set of smart contracts running on RGB++ Layer monitors the guardians of the bridge. If the guardian behaves maliciously, their collateral will be slashed. If the guardians collude to steal the locked BTC, rBTC holders can get full compensation.
After combining Leap and Wrapper, various assets in the BTCFi ecosystem such as RGB++ native assets, BRC20, ARC20, runes, etc. can cross to other layers or public chains.
The figure below is part of the use process of applying LeapX. You can see that it supports the interoperability of almost all BTCFi mainstream assets to different ecosystems. And there are corresponding processing procedures for assets with different issuance methods, some of which use wrappers, and some use leap.
Above, we mainly explained the isomorphic binding and Leap concepts of RGB++ Layer. Let's examine other key points below.
In traditional BTCFi, due to the lack of support for smart contracts, only some relatively simple Dapps can be implemented. Some implementation methods will have certain centralization risks, while others are clumsy and inflexible.
In order to realize a smart contract layer available on the blockchain,CKB provides CKB-VM for RGB++ Layer. Any programming language that can support RISC-V virtual machines 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 in a unified smart contract framework and execution environment.
The following is a transfer method for user-defined tokens UDT in CKB implemented in C language. It can be seen that except for the different languages, its basic logic is the same as that of general tokens. And because RISC-V has a wide range of language and compiler support, the entry requirements for developers to develop smart contracts are relatively low. We can easily rewrite this logic in 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 a specific smart contract framework is inevitable.
Finally, let us briefly understand the native AA and account abstraction ecology behind the RGB++ Layer. Since the essence of BTCFi is to provide a diverse DeFi experience for native Bitcoin assets, compatibility with mainstream Bitcoin wallets will be an important factor that BTCFi's peripheral facilities need to consider. The RGB++ Layer directly reuses CKB's native AA solution, which can be compatible with important UTXO public chains such as BTC and Cardano as much as possible on both the developer side and the user side.
In the RGB++ Layer, users can use different signature algorithms for authentication. For example, users can use accounts, wallets or authentication methods such as BTC, Cardano, or even WebAuthn to directly manipulate assets on the RGB++ Layer.
Let's take the wallet middleware CCC below as an example. It can provide wallets and dApps with various public chains for CKB operability.
The figure 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, and CKB Eco Wallet JoyID is a typical representative. Through JoyID, users can directly authenticate through biometrics (such as fingerprint or facial recognition) to achieve seamless and highly secure login and identity management.
It can be said that the basis for the establishment of homogeneous binding and Leap is that RGB++ Layer has a complete native AA solution, which can be well compatible with the account standards of other public chains. This feature is not only convenient for supporting some key scenarios, but also can clear obstacles for UX.
In the above, we have examined the overall picture of RGB++ Layer. It can serve as an important infrastructure for various Memecoins such as inscriptions/runes/dyed coins to realize the scene of full-chain interaction. 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 the limited space, this article only briefly introduces the core technology of RGB++ Layer, and does not systematically introduce 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!
RGB, Arche Network, UTXO binding: Detailed explanation of BTC smart contract solutions RGB, RGB++ and Arch Network Golden Finance, Bitcoin is currently the most liquid and secure blockchain.
JinseFinanceCipher, co-founder of CKB and proposer of RGB++, talked about the unique significance of RGB++ Layer and UTXO model to BTCFi, and some questions and opinions about CKB and Bitcoin ecology.
JinseFinanceAfter CKB launched the Bitcoin layer 1 asset issuance protocol RGB++ in the first half of the year, it has now launched CKB RGB++ Layer, which will not only ignite Bitcoin Finance (BTCFi), but may also drive all UTXO chains to take off.
JinseFinanceRGB++ Layer is a concept upgraded from the RGB++ protocol, representing a higher level of abstraction that extends isomorphic binding, smart contract capabilities, and bridgeless cross-chain functionality to all UTXO chains.
JinseFinanceRGB++ has finally updated to RGB++ Layer with a complete DeFi suite. What opportunities are there? This article will reveal them to you one by one with plain language and vivid cases.
JinseFinanceLet’s talk about RGB++ and CKB, the dark horse of this bull market, to explore the relationship between RGB++ and RGB, and why RGB++ should be upgraded to RGB++ Layer.
JinseFinanceOne-time seals are the cornerstone of the RGB/RGB++ protocol, which expands the capabilities of Bitcoin.
JinseFinanceWhen the RGB++ protocol was first launched, the market was very enthusiastic. The first use case of the “isomorphic binding” technology proposed by RGB++ combined the BTC network and the CKB network, which also triggered people’s new understanding of the CKB network.
JinseFinanceThe top priority of this ecosystem now is to vigorously improve the user experience and quickly attract users to participate in its ecosystem construction.
JinseFinanceThe competition among third-party settlement layers under the Bitcoin chain may begin soon.
JinseFinance