The following content is reproduced from OneKey Chinese, with some deletions and modifications. Original link: https://x.com/i/web/status/1759039068913197391
A few months ago, Nervos Network announced the promotion of CKB as the first "PoW+UTXO" Bitcoin L2.
Before this, when discussing BTC L2 in the community, it was actually deeply influenced by the L2 Rollup concept of Ethereum. Previously, various quickly built EVM versions of L2, although technically mature and with low ecological development thresholds, have always been criticized for their native security. At the same time, using this type of L2 requires users to switch back and forth between BTC wallets and EVM wallets, which is not a very elegant user experience. In short, before these problems are solved, it may not be easy for the "picky" OG and whales in the BTC community to be "FOMO". Under these various problems, whether the UTXO isomorphic L2 solution can become a new way out has become a hot topic recently.
This article is aimed at beginners and provides an introduction to the development of the inscription and CKB's "non-cross-chain bridge" BTC L2, starting from the "source of all evil" UTXO.
What are UTXO and eUTXO?#
UTXO (Unspent Transaction Output) means "unspent transaction output" in literal translation. For example, if you receive a transfer of 10 BTC and have not spent it on others, this 10 BTC is a UTXO.
Let's understand through comparison and examples.
Currently, there are two mainstream transaction record models in blockchain, namely UTXO model and account model. The account model used by Ethereum is very easy to understand. This model is similar to bank accounts and Alipay/WeChat accounts. In this model, the total amount of funds in the account is intuitively displayed as a whole balance, and the system only needs to track the balance changes of user accounts. For example, if there is a balance of 1000 yuan in your account and you purchase a OneKey Classic for 600 yuan, the system will deduct 400 yuan from your account and add 400 yuan to the OneKey account.
Compared with the account model used by Ethereum, the UTXO model of Bitcoin is more like a real "wallet" and "banknote", more like real cash transactions. For example, imagine you have a wallet with many banknotes of different denominations. Each banknote can be regarded as a UTXO, that is, money you can use. In a system like Bitcoin, when you receive Bitcoin transferred by others, this money is like a new banknote in your wallet that you haven't used to pay for other things, so it is "unspent".
Every time you make a transaction, such as using a banknote of 1000 yuan to buy a OneKey Classic for 600 yuan, you will get 400 yuan in change. In the Bitcoin system, this operation is equivalent to using a UTXO (1000 yuan) to create two new UTXOs: one is paid to OneKey (600 yuan), and the other is returned to yourself (400 yuan). You "spend" the original UTXO (1000 yuan) and "generate" new UTXOs (600 yuan and 400 yuan) at the same time.
With the above, the concept of eUTXO (Extended Unspent Transaction Output), becomes easy to understand. In systems like Cardano that use the eUTXO model, it not only records the amount of money but also can contain more complex data and logic (for example, this money can only be used to purchase specific goods or services). In this way, each transaction not only transfers funds but can also execute some conditions or even the content of smart contracts. This makes transactions more flexible but also more complex.
The Relationship Between BRC-20 and UTXO#
If you are familiar with the BRC-20 protocol, you will soon realize that "damn, what they are doing is running the account model on top of the UTXO model." After all, the name of the protocol is derived from the ERC-20 token standard of Ethereum, which uses the account model.
In BRC-20, token operations, including deployment, minting, and transfer, are implemented by embedding JSON-formatted data in UTXO transactions on the Bitcoin blockchain. This is equivalent to writing on the "banknote" mentioned earlier. This allows free issuance of tokens on the Bitcoin chain. However, Bitcoin cannot manage the account model, and the content of BRC-20 is stored in the Taproot script of Segwit, which Bitcoin cannot recognize and calculate. It's like a bank system only recognizes the denomination of banknotes and doesn't care what you write on them.
Fortunately, unlike centralized banks, all Bitcoin transactions are public, and we can see what is written on all "banknotes". As long as we follow certain rules (ordinal theory) to do the bookkeeping and perform calculations off-chain, we can do it. So currently, the BRC-20 protocol adopts an off-chain approach to build an indexing server to perform various bookkeeping calculations for BRC-20 tokens. However, this approach obviously carries the risk of centralization—this service that maintains the ledger does not have a fair game mechanism of PoW or PoS to ensure that it does not do evil. This also explains why BRC-20 is seen by some Bitcoin core developers and geeks as redundant and a technological regression.
Therefore, various new inscription protocols have been developed to address the shortcomings of BRC-20. For example, ARC-20 and Runes have adopted a similar method to calculate the balance of Bitcoin in the UTXO, directly making the quantity of tokens equal to the quantity of Bitcoin in the UTXO (unit: satoshi)—1 token = 1 satoshi, instead of counting separately. This is equivalent to putting a "special mark" on the banknote of the smallest denomination to represent another currency. In fact, it is a "colored coin" that appeared in the ancient history of the cryptocurrency world.
The advantage of doing this is that it does not require any off-chain systems for tracking transactions and calculating balances. It only requires an indexing server to identify this "special mark", reducing the cost of the indexing server.
But this also introduces a new problem. In order to reduce junk transactions, the Bitcoin network has a minimum transaction output limit (546 satoshi), which makes inscription tokens like ARC-20 unable to split into finer-grained transactions, resulting in liquidity similar to NFT and not true fungible tokens. However, to introduce the calculation of split transactions, it is necessary to perform centralized off-chain indexing transactions. ARC-20 has been stuck on this issue for a long time, and there has been no solution for splitting for several months. Currently, it seems that the project team hopes to implement pledge splitting calculations inspired by BitVM's AVM, which is not an easy development task.
How does CKB implement a non-cross-chain bridge L2?#
From a technical perspective, many meme-type inscription asset issuance schemes themselves have limited the advancement of Bitcoin technology. Inscription has created many new assets, but applications have been limited to asset issuance.
However, the wealth effect and FOMO of inscription have allowed people to see the imagination of the BTC ecosystem. In the practical needs of on-chain players, the various restrictions of the Bitcoin network and UTXO have stimulated people's demand for Bitcoin scalability and more complex ecological applications.
From the perspective of scalability, the Lightning Network is already a great L2. The Lightning Network achieves trustless and has been running for many years through games (punishment-based revocable commitment transactions). However, the state channel architecture of the Lightning Network is basically limited to payments and cannot achieve more complex intentions.
As mentioned earlier, a relatively secure and elegant L2 can be achieved by using the UTXO model that is isomorphic to BTC and extending it with the eUTXO concept. Public chains Ergo and Cardano have made progress on the eUTXO model and have implemented smart contract functionality. However, CKB was the first to think of implementing an L2 solution.
CKB's answer is to propose the RGB extension protocol: RGB++. In fact, it is more like a "major modification" than an extension. CKB's extension inherits the core of the RGB protocol but directly adopts different virtual machines and verification schemes. The RGB protocol, as an open-source smart contract system protocol, is designed to run scalable, robust, and private smart contracts on UTXO blockchains such as Bitcoin and Liquid. Currently, v0.11 has not been released yet, and its virtual machine AluVM still has some distance to go before it is fully implemented (some say it may not be able to be done until the end of this bull market).
The technical focus is on "isomorphic binding", which maps Bitcoin UTXOs to Nervos CKB's Cells—a modified version of UTXO that can combine to implement smart contract capabilities. For the verification scheme, all RGB++ transactions will appear in both the BTC and CKB chains. The original off-chain client verification has been changed to on-chain public verification of CKB, which is much more user-friendly and does not require the use of independent clients or the storage of original transaction data.
Roughly speaking, the RGB++ assets issued on the Bitcoin layer can be used on the CKB layer to implement various complex intentions using smart contracts, without the need for any cross-chain bridges.
In a sense, this is a relatively cutting-edge idea—to achieve cross-chain scalability based on intentions, rather than traditional asset cross-chain.
L2s are always trying to lock BTC on L2 in various ways, but to achieve scalability and complex applications, it may only be necessary to do intention-based applications on L2.
Currently, RGB++ has been launched, and the ecosystem is developing rapidly. I believe this solution will provide a new path for the exploration of BTC L2 orthodoxy, and the future looks promising.