Author: Lao Bai;; Source: X@Wuhuoqiu
UTXO Stack, led by ABCDE, can technically help project developers issue BTC Layer2 based on UTXO architecture with one click, and natively integrate RGB++ protocol capabilities. In terms of security, it combines staking BTC, CKB and BTC L1 assets to ensure the security of Layer2.
In short, UTXO Stack is the "OP Stack + EigenLayer" of the Bitcoin ecosystem.
If you want to explain UTXO Stack clearly, you can't avoid RGB++.
There are more than 20 BTC Layer2 on the market, but most of them are EVM solutions, which basically use ETH's technology stack + bridge to solve BTC's expansion problem. Although the ecosystem can be quickly built in the short term, in the long run, this solution has no strong binding relationship with the BTC main chain in terms of security, and is heavily dependent on the bridge. Secondly, it is ideologically using ETH's Account model and EVM virtual machine to expand the capacity of UTXO's BTC, which seems somewhat not "Bitcoin Native".
While the security is highly correlated with BTC L1, and the solution is sufficiently BTC Native, the Lightning Network has not achieved the desired effect after years of operation, and has a natural expansion shortcoming of not being able to support smart contracts. Solutions of client verification paradigms such as Taproot and RGB also have many problems such as long landing time and slow technological progress. This is also the main reason why the current EVM expansion solution is popular.
Nervos, which has been deeply involved in the public chain field for many years, uses the natural structural advantages of POW+UTXO like BTC + innovative "isomorphic mapping" technology to "seamlessly move" the client verification paradigm of RGB to CKB, named RGB++. It sacrifices a little privacy in exchange for a great expansion of functionality and flexibility, and its security is strongly bound to BTC L1. More importantly, RGB++ was actually launched a few days ago! This means that this is no longer a narrative of expansion that remains at the conceptual or development level, but a product that can actually start to build an ecosystem and solutions.
If the above terms like client verification and isomorphic binding are still too abstract, then the following approximate analogy can be used to understand RGB++ - A user initiates a transaction on BTC L1 to trigger the RGB++ asset transaction belonging to the user on CKB. When this transaction is completed on CKB, it is written back to the previous Commitment on BTC L1. You may be wondering - this doesn’t save the Gas fee, right? Users still have to initiate transactions on BTC L1 and still have to pay the Gas fee on BTC. Now they have to add the Gas fee on CKB. It feels more expensive, right?
Actually, it is not. There are four benefits:
1. RGB++, as an asset issuance protocol, enables BTC L1 to have the ability to issue new RGB assets (think of Merlin's BRC420)
2. RGB++ asset transactions on CKB are completely Turing complete and programmable
3. You can wait for multiple RGB++ transfers to be completed, and then aggregate and send a Commitment to Bitcoin L1. This is called "transaction folding", which is very Rollup-like, and saves a lot of Gas fees
4. Not only RGB++ assets can be mapped to CKB, but Atomical, Rune and other assets with UTXO characteristics can also be mapped to CKB for Turing complete transactions