The Good Tech Companies - RGB++ Layer as Hub of BTCFi and UTXO: Four Main Characteristics

Episode Date: July 31, 2024

This story was originally published on HackerNoon at: https://hackernoon.com/rgb-layer-as-hub-of-btcfi-and-utxo-four-main-characteristics. The core technologies of the RGB++ Layer to realize full-chain interaction scenarios including for various meme coins and inscriptions/runes/colored coins. Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #bitcoin, #rgb++, #rgb++-layer, #utxo, #cardano, #crosschain, #defi, #good-company, and more. This story was written by: @rgbpp. Learn more about this writer by checking @rgbpp's about page, and for more stories, please visit hackernoon.com. The RGB++ Layer uses isomorphic binding and Leap to provide a "bridge-free" cross-chain interaction experience. It leverages CKB's Turing-complete smart contract environment to build the necessary conditions for Bitcoin to issue assets and implement complex DeFi functions. It also paves the way for the large-scale adoption of BTCFi.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. RGB++ Layer as Hub of BTC-FI and UTXO. Four Main Characteristics by RGB++ Layer. Author, Faustin Wuye, from GeekWeb3 and BTC Eden The announcement of the launch of the RGB++ Layer this month, July 2024, marks the complete transition of the previously released RGB++ protocol from Theory Tone Engineered product. With its grand vision of building a BTC-FI ecosystem on BTC, CKB, Cardano, and other PAN UTXO, unspent transaction output, public chains, the RGB++ layer's launch also helps introduce more specific and practical scenarios for the platform thus making it become the focus of attention for countless people.

Based on the RGB++ protocol, the RGB++ layer uses isomorphic binding and leap to Pro Vita. Bridge-free, cross-chain interaction experience for RGB++ native assets or inscriptions, runes between BTC, CKB, Cardano, and other UTXO-type public chains. It leverages CKB's Turing-complete smart contract environment to build the necessary conditions for Bitcoin to issue assets and implement complex DeFi functions. Considering that CKB's comprehensive account abstraction ecosystem backs it and is compatible with Bitcoin accounts and wallets, it also paves the way for the large-scale adoption of BTCFI. This piece is to help understand the general working principles and functional characteristics of the RGB++ layer. It also highlights the changes the layer will bring

to the BTCFI ecosystem based on its four distinctive characteristics. 1. RGB++ protocol is the theoretical foundation of RGB++ layer. The RGB++ protocol was released in January to replace the client-side verification of the RGB protocol with the CKB on-chain verification. It uses CKB as a decentralized indexer, delegating tasks such as data storage and asset source verification to CKB, with the latter serving as the verification layer and data availability, DA, layer for the RGB protocol. This is to help Solvian spent transaction, UX, issues and unfavorable defects in DeFi scenarios in the RGB protocol. In line with the concept of one-time encapsulation, RGB++ S isomorphic binding uses cell and extended UTXO on the CKB chain as the data carrier for inscription,

rune-type assets to establish a binding relationship with UTXOs on the Bitcoin chain to inherit Bitcoin's security. For example, if Alice wants to transfer some test tokens to Bob, she can generate a declaration that binds the cell storing test asset information to one of Bob's Bitcoin UTXOs. If Bob wants to transfer the test tokens to someone else, the bound Bitcoin UTXO must also be transferred. In this way, there is 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 cannot be double-spent. With this mechanism, the RGB++ assets have

inherited Bitcoin's security. The RGB++ layer is a product of the engineering implementation of the RGB++ protocol. Its two main features are isomorphic binding and leap bridge-free cross-chain. 2. Isomorphic binding and leap, asset issuance and bridge-free cross-chain layer FORBTC FITO understand the isomorphic binding and leap approach, explaining CKB's cell model is essential. A cell is an extended UTXO with multiple fields such as lock script, typescript, and data. The lock script functions similarly to Bitcoin's locking script, used for permission verification, typescript is similar to smart contract code, while data is used to store asset data.

If you want to issue RGB++ assets on the CKB chain, create a cell first and write the token symbol and contract code in the relevant fields. Then you can break down the cell and distribute it to many people, just like the splitting and transfer of Bitcoin UTXOs. With the cell's structural similarity to Bitcoin UTXOs and CKB's similarity with Bitcoin's signature algorithm, users can manipulate assets on the CKB chain using Bitcoin wallets. As the owner of a cell, you can set its locking script so that its unlock condition is consistent with that of a Bitcoin UTXO, allowing you to directly manipulate cells on the CKB chain

using a Bitcoin account's private key. The features highlighted above can also be implemented between CKB, BTC, and OTHER UTXO public chains. For example, you can use a Cardano account to rewrite asset data on the CKB chain, and the control rights of RGB++ assets get transferred from a BTC account to a Cardano account without a cross-chain bridge. Remember that the binding of RGB++ assets to UTXOs on public chains such as Bitcoin, Cardano, Liquid, etc., similar to how bank accounts are bound to customers' phone numbers and ID's in real-life cases, is to prevent double spending. It should also be noted that RGB++ assets are a bunch of data that needs media storage like in a database. Cells on the CKB chain can serve as their database. Then the permission verification

could be set to allow access to accounts from different public chains like BTC and Cardano to rewrite RGB++ asset data on the CKB chain. The Leap and bridge-free cross-chain proposed by RGB++ layer are based on the isomorphic binding technology. They serve the purpose of rebinding for the UTXOs bound to RGB++ assets. For example, if your assets were previously bound to Bitcoin UTXOs, they can now be rebound to UTXOs on Cardano, Liquid, Fuel, and other chains. As a result, asset control permissions are transferred from BTC accounts to Cardano or other accounts. From the user's perspective, this is equivalent to asset cross-chaining, with CKB playing a role similar to an indexer and database. However, unlike traditional cross-chain methods, LEAP only

changes the permission to modify asset data, while the data itself is still stored on the CKB chain. This method is more concise than the lock-mint model and eliminates the dependency on mapped-as-set contracts. Technical implementation approach of isomorphic binding. Assuming Alice has 100 test tokens whose data is stored in cell number 0 and has a binding relationship with UTXO number 0 on the Bitcoin chain. To transfer 40 test tokens to Bob, she needs to split cell number 0 into two new cells, where cell number 1 contains 40 test tokens to be transferred to Bob and cell number 2 contains 60 test tokens still controlled by Alice. In this process, the BTC UTXO number 0 bound to cell number 0 has to be split into UTXO number 1 and UTXO number 2 and then bound to cell number 1 and cell number 2 respectively.

So when Alice transfers cell number 1 to Bob, she can transfer BTC UTXO number 1 to Bob, too, with one-click touchive synchronous transactions on CKB and BTC chains. The core significance of isomorphic binding is its adaptability. This ISP articularly key since CKB's cell, Cardano's EUTXO, and Bitcoin's UTXO are all UTXO models, and CKB is compatible with Bitcoin, Cardano signature algorithms. The operation methods of UTXOs on both the Bitcoin and Cardano chains also work for cells on the CKB chain. This way, Bitcoin-Cardano accounts can directly bias to control both RGB++ assets on the CKB chain and their bound Bitcoin-Cardano UTXOs simultaneously, achieving one-to-one synchronous transactions. Going by the Alice transferring to

Bob scenario above, the general workflow eases follows 1. Alice constructs a CKB transaction data locally, not on-chain yet, specifying that cell number 0 will be destroyed, cell number 1 to be sent to Bob is generated, and cell number 2 to be kept for herself. 2. Alice generates a declaration locally, binding cell number 1 to UTXO number 1 and cell number 2 to UTXO number 2, and sending both cell number 1 and UTXO number 1 to Bob. 3. Then, Alice generates a commitment, similar to a hash, locally, corresponding to the original content including the declaration from step 2 plus the CKB transaction data generated in step 1. 4. Alice initiates a transaction on the Bitcoin

chain, destroys UTXO number 0, generates UTXO number 1 to be sent to Bob, keeps UTXO number 2 for herself, and writes the commitment to the Bitcoin chain in the form of an OP underscore return opcode. 5. After step 4 is completed, the CKB transaction generated in step 1 is sent to the CKB chain. Note that the cell and the corresponding Bitcoin UTXO are isomorphically bound and can be directly controlled by Bitcoin accounts. That is, during the interaction process, users can perform one-click operations through Bitcoin accounts in the RGB++ wallet. Hence, RGB++ assets bound to Bitcoin UTXOs help solve the double spending problem as assets on the RGB++ layer inherit Bitcoin security. The above scenario is not limited to isomorphic binding between bitcoin and ckb but also applies to a broad scope of

chains including cardana liquid litecoin etc implementation principle and supported scenarios of leap the leap function is basically to switch the utxo bound to rgb plus plus assets e g changing the binding from bitcoin to cardana after which you can control RGB++ assets using Cardano accounts. In such an instance, a transfer could still be made on the Cardano chain afterward, splitting and transferring the UCHO-controlling RGB++ assets to more people. While RGB++ assets can be transfer-read and distributed on multiple UTXO public chains, they can bypass the traditional cross-chain bridge lock mint model. In this process, the CKB public chain plays a role similar to an indexer,

witnessing and processing leap requests. Suppose you want to transfer RGB++ assets bound to BTC to a Cardano account, the core steps to follow are 1. Publish a commitment on the Bitcoin chain, declaring the unbinding of the cell bound to the BTC UTXO. 2. Publish a commitment on the Cardano chain, declaring the binding of the cell to the Cardano UTXO. 3. Change the locking script of the cell, changing the unlock condition from a Bitcoin account private key to a Cardano account private key. Take note that the RGB++ ACID data is still stored on the CKB chain throughout this process. The unlock condition is changed from a Bitcoin private key to a Cardano private key. Of course, the specific execution process is much more complex than

described above but we won't elaborate on it here. In the leap to non-CKB public chains, the implicit premise is that the CKB public chain acts as a third-party witness, indexer, and DA facility. This is because, as a public chain, its credibility far exceeds traditional cross-chain bridge methods such as multi-party computation, MPC, and multi-signature. Another interesting scenario that can be implemented based on the leap functionize, full-chain transactions. An example of this scenario is when an indexer is set up across Bitcoin, Cardano, and CKB to build a trading platform that allows buyers and sellers to trade RGB++ assets. In such an instance, buyers can transfer their Bitcoins to sellers and receive

RGB++ assets with their cardano accounts throughout the process the data of rgb plus plus assets is still recorded in cells which are transferred to the buyer and their unlock permissions are changed from the seller's bitcoin private key to the buyer's cardona private key wrapper although the leap function is perfect for rgb plus plus assets there are still some bottlenecks for bitcoin Bitcoin and Cardano, RGB++ assets are essentially inscriptions, runes, colored coins based on the op underscore return opcode. The nodes of these public chains cannot perceive the existence of RGB++ assets, as CKB participates in coordination ASAN indexer. In other words, for Bitcoin and Cardano,

the RGB++ layer mainly supports the leap of inscriptions, runes, colored coins, rather than the cross-chain of native assets like BTC and ADA. As a remedy, the RGB++ layer introduced Wrapper, a bridge based on fraud proofs and over-collateralization. Taking the RBTC Wrapper as an example, it bridges BTC to the RGB++ layer. A set of smart contracts running on the RGB++ layer monitors the guardians of the bridge. If the guardians act maliciously, their collateral will be slashed. If they collude to steal locked BTCs, RBTC holders will be made to receive full compensation. With the combination of Leap and Wrapper, various assets in the BTCFI ecosystem A.G. RGB++ native assets, BRC20, ARC20, Runes, etc.

can be bridged to other layers or public chains. The following diagram shows part of the usage process of LeapX. It supports the interoperability of almost all mainstream BTCFI assets to different ecosystems. There are corresponding processing flows for assets issued in different ways with some using either wrappers or Leap. 3. CKBVM. The smart contract engine for BTCFI due to a lack of support for smart contracts in traditional BTCFI, only relatively simple decentralized applications, DAPPs, can be implemented in the evolving space. Some implementation methods may have certain centralization risks, while others are rather clumsy or inflexible. To have a blockchain-available smart contract layer,

CKB introduced the CKB VM through the RGB++ layer. It aims to make it possible for any programming language that supports the RISCV virtual machine to be used for contract development on the RGB++ layer. It enables developers to use their preferred tools and languages to develop and deploy efficient and secure smart contracts under a unified smart contract framework and execution environment. Generally, the entry requirements for developers' smart contract development with RISCV are relatively low because of its extensive language and compiler support. Of course, language is only one aspect of programming, and learning specific smart

contract frameworks is inevitable. However, with the RGB++ layer, the logic can be easily rewritten in JavaScript, Rust, Go, Java, and Ruby, rather than learning a specific DSL language to write contracts. The diagram below shows a method for transferring user-defined tokens, UDT, with CKB using C language language aside from the different languages its basic logic is the same for general tokens for native ecosystem seamlessly connecting btc and rgb plus plus finally since btcfi is to essentially provide diverse defy experiences fornitive bitcoin assets understanding the account abstraction ecosystem behind rgb RGB++ layer along with its mainstream Bitcoin wallets is an important factor for BTCFI peripheral facilities to consider.

RGB++ layer directly reuses CKB's native Awe solution, which is compatible with main UTXO public chains like BTC and Cardano on both the developer and the user sides. With the RGB++ layer, different signature algorithms can be used for authentication. That is, users can directly manipulate assets on the RGB++ layer using BTC, Cardano, or even web auth in accounts, wallets, or authentication methods. An example is the wallet middleware, CCC, which can provide various publicchains operability to CKB for wallets and DAPPs. The following image shows the connection window of CCC and how it supports mainstream wallet entries such as Unisat and Metamask. Another example is the implementation of WebAuthn with JoyID, a CKB ecosystem wallet, being a typical representative.

JoyID users can directly authenticate their accounts through biometric methods, such as fingerprint or facial recognition, to achieve seamless and highly secure login and identity management. It can be said that the RGB++ layer has a complete native Awe solution, which can also accommodate the account standards of other public chains. This feature not only facilitates support for some key scenarios, but also clears obstacles for UX. Summary, this article introduced the core technologies of the RGB++ layer without explaining several complex details. It highlights that the RGB++ layer can be an important infrastructure for realizing full

chain interaction scenarios including for various meme coins and inscriptions, runes, colored coins. The layer's RISCV-based smart contract execution environment can also help create the soil for the complex business logic required by BTCFI to grow. As the RGB++ layer progresses, a more thorough analysis of the series of technical solutions related to the project will be provided. Please stay tuned. Thank you for listening to this HackerNoon story, read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.