The UTXO Stack was recently better explained to some enthusiasts, developers, token holders, and newcomers who might have heard about or are just getting acquainted with it. The audience was schooled on what the RGB++ protocol stands for, the essence of its complete edition, and its plans. It began with highlighting the RGB++ protocol mission and positioning which center on constructing native programmability and scalability solutions for the Bitcoin ecosystem i.e. in a manner that is inherently native. The need to go the native way, says the co-founder of Nervos CKB, Cipher, “is not just a political thing, it is more about a native way that could provide a vital solution.”
This article is based on a talk by
What 'native' means
It refers to utilizing Bitcoin's inherent features—Proof of Work (PoW) and Unspent Transaction Outputs (UTXO). Only by leveraging these two features can a native approach be claimed as being used to offer a superior solution. It differs completely from the Ethereum ecosystem which relies on an account model and Proof of Stake (PoS).
In recent years, the Ethereum ecosystem has had various scalability solutions including Plasma, Sharding, the Raiden Network, and Rollups. Rollups have emerged as the optimal solution for Ethereum's scalability because they fully capitalize on the advantages of the account model and PoS.
However, while it worked for Ethereum, the same assumption does not automatically apply to Bitcoin that rollups are its best solution. Rather, other or even better solutions are being explored. These include the four primary directions for Bitcoin scalability or extension approaches:
-
Sidechains: These comprise a bridge, specifically multisig bridges, and an EVM-compatible layer 2 (Bridge+EVM). Merlin, BEVM, and Satoshi VM are among the best examples. However, they are not truly Bitcoin layer 2 solutions but rather bridges to an Ethereum layer 2. Their security depends on the multisig bridge and there has been limited innovation in this area.
-
Rollups: To verify the layer 2 status directly on Bitcoin's layer 1, something special is needed in the Bitcoin script. So, a highly sophisticated technology like BitVM with the potential support of OP_CAT is meant to make achieving this easier though challenging. Meanwhile, there is a general belief in the space that BitVM is not likely to complete its development within this current Bitcoin bull market cycle. Thus, the rollup solution might be realized by the next bull market which is expected in the next four years.
-
Channels/LN: Channels and the Lightning Network are called the Bitcoin native scalability approaches. We already have a mature Lightning Network operating on Bitcoin, with over 10,000 nodes and millions of users. However, this network currently only supports Bitcoin. If it could, one day, support stablecoins or other user-defined coins, it would be significantly more useful. The CKB team is also developing a CKB Lightning Network, which is expected to connect with the Bitcoin Lightning Network this year. This is a very promising solution for Bitcoin though it is more dedicated to payment channels or networks and faces challenges.
-
CSV (Client-Side Validation): This is a Bitcoin-native solution available only for the UTXO model. Notable projects include RGB, Taproot Assets, and RGB++ protocol.
The Problem
Despite more than a hundred layer 2 solutions being built on the Bitcoin chain, none has been able to address the programmability and scalability problem. The most mature Bitcoin layer 2 solutions follow the multisig bridge plus EVM-compatible layer approach. They essentially bridge the real Bitcoin chain to another chain with bitcoins that are not real (shadow or pseudo bitcoins). Without a truly native solution, the shadow bitcoins remain unprogrammable and unscalable because the real Bitcoin remains on layer 1.
There comes the RGB++ protocol’s straightforward solution: It enables Turing-complete programmability directly on Bitcoin layer 1 and extends to layer 2 to achieve scalability.
Therefore, in a nutshell, the RGB++ protocol is not BitVM even though it can provide native Turing-complete capability on Bitcoin layer 1. It neither relies on any new OP codes nor does it require hard forks or soft forks but rather directly provides programmability on layer 1. It also is not an EVM or a rollup, and it does not need a bridge.
RGB++: How it works
Every Bitcoin UTXO consists of two critical components, one for the amount field (variable) to indicate the bitcoin contained within the UTXO and another for the lock script which is akin to an address that signifies ownership and authority to unlock the UTXO.
The RGB++ protocol attaches additional data as an extra program logic to the original Bitcoin UTXO. A single Bitcoin UTXO is linked with an off-chain data cell (or what is termed a Turing-complete UTXO). By connecting every on-chain UTXO with off-chain data and extra execution logic, the off-chain UTXO is transferred—-despite being constrained by the script on the UTXO—-whenever the original UTXO is transferred or spent. This allows the transfer of additional bits or assets from one UTXO to another, executing the script and effectively forging an off-chain transaction with off-chain state transfer from one state to another. This is the essence of the RGB++ protocol.
The method is referred to as isomorphic binding because the RGB++ protocol’s off-chain state transitions are verified by another Turing-complete UTXO-based PoW chain, CKB, to ensure transaction accuracy. Compared to the original RGB protocol, which runs off-chain processes on the user's client, the RGB++ protocol runs these processes on the CKB chain. However, this is optional for users. Those who do not trust CKB can download the transaction or request the transaction history from the sender and verify it themselves.
To explain the isomorphic binding technology further, look at the diagram above. The left side represents the Bitcoin transaction while the right side is for the CKB transaction. The CKB side could be considered an "off-chain transaction" when compared to the Bitcoin on-chain transaction though it is an on-chain transaction when seen from the CKB perspective. The Bitcoin inputs and outputs sections signify asset or state ownership while the commitment, encoded in the OP_RETURN field of the Bitcoin transaction, is a hash of the CKB transaction.
The CKB transaction side includes a UTXO with a rich state— anything under smart contract protection. It also has a Bitcoin light client on the CKB chain that acts as a proof generator or verifier. When a transaction’s proof is triggered, the smart contract verifies whether the transaction is correctly encoded in the Bitcoin commitment. This technology helps achieve a bi-directional binding of the Bitcoin transaction and UTXO with the CKB transaction and CKB Cell, ensuring that the transaction is controlled or constrained by the CKB smart contract. This is how programmability is achieved on the Bitcoin layer 1 with the RGB++ protocol.
The basic knowledge of the RGB++ protocol and its use as the isomorphic binding method can be used to introduce the Cross-chain Leap action. Since the Bitcoin inputs and outputs sections signify asset or state ownership, transferring the ownership from a Bitcoin UTXO to another chain's UTXO e.g. Litecoin, requires changing the isomorphic binding data structure from Bitcoin UTXO to Litecoin UTXO. However, when the transfer happens, nothing changes in the value it carries.
This is the essence of the Cross-chain Leap. It eliminates the need for any bridges, either centralized or decentralized, while it enables a simple transfer from one chain to another. Verifying the transaction is also straightforward. It traces back the transaction history with the proof of the UTXO branch on one chain and another until it gets to the initial Bitcoin chain.
A good example of how this asset leap is achieved can be seen in Bitcoin’s first non-custodial passkey wallet application,
Armed with these utilities—layer 1 programmability and cross-chain leap technology, the final step of the RGB++ protocol can be achieved: creating a scalability extension for Bitcoin layer 2. We can construct a UTXO-based layer 2 with PoS.
Verify PoS without malicious activities
To implement staking, rewarding, and slashing on Bitcoin layer 1, the programmability layer provided by RGB++ protocol is used to run staking or slashing scripts which provide security to the UTXO layer 2. This functionality enables assets to be leaped from UTXO layer 2 to layer 1 without any centralized or decentralized bridge. This is what UTXO Stack does, as the complete edition of the RGB++ protocol.
For security and staking, Babylon or similar protocols will be introduced as the Bitcoin staking security provider for L2 chains while other tokens such as CKB and RGB++ coins can be accepted as staking assets on layer 1 as programmed in the RGB++ protocol smart contracts. The security level for Bitcoin layer 1 is identical to that of Bitcoin itself. It is guaranteed by Bitcoin’s historic PoW chain. The security for layer 2s is akin to an OP rollup (on Ethereum) with an expected challenging period in which there will be a security cap that is similar to the deposit. After the challenging period is over, the security is expected to be better.
With this complete edition of the RGB++ protocol plan, the team and company are dedicated to building the UTXO stack solution focusing on Bitcoin's scalability. The plan is to develop something akin to the OP Stack + EigenLayer for Bitcoin, which is UTXO native and neither EVM compatible nor has any bridge. It can integrate with future lighting networks and is expected to be the best solution for Bitcoin's extension instead of a rollup solution.
Efforts are ongoing to build on the robust community and ecosystem that have been cultivated so far with projects such as fungible token and non-fungible token marketplaces, launchpads, DOBs, Stable++, Leap X, Omega, Nervape, JoyID wallet, etc.
Click