Preface
As the hot spot of this round of bull market, Bitcoin ecology has emerged with a series of dazzling new words such as inscriptions, runes, BRC, ARC, RGB, RGB++, etc. So, what is the Bitcoin layer 1 asset protocol, and what are the differences between the various protocols? In this regard, Mr. Cipher gave a lecture with clear logic and easy-to-understand content in the public class "Overview of BTC Layer 1 Asset Protocol" in the Denglian community.
Today, Baozi will lead everyone to follow Teacher Cipher’s explanation, using the issuance of “Hamburger Coin” as a guide to easily understand the nature and differences of these asset protocols.
Thanks to Zhou Zhou for providing professional technical guidance, thanks to Wei Wei for valuable suggestions on the text, and thanks to a ball for providing the exquisite cover image for this article.
Original public class Link: https://www.youtube.com/watch?v=mgUxYU5tcJM
I. Basic Theory
Before understanding the layer protocol of Bitcoin, it's essential to know some basic theories, including the Bitcoin model, UTXO and account models, etc.
Bitcoin Measurement Model
Bitcoin is referred to as digital gold, naturally having measurement units like gold. The units for gold include kilograms, grams, ounces, etc., with the smallest unit being an ounce. The smallest unit of Bitcoin is 'satoshi,' with one 'satoshi' being one hundred millionth of a Bitcoin.
Bitcoin Transaction Model
The transaction model of Bitcoin is UTXO (Unspent TX Output). Each transaction consists of several inputs (Input) and several outputs (Output). Each Input can point to a previous Output, and each UTXO contains a certain amount of Bitcoin, with a gas fee required for the transfer. When we transfer Bitcoin to someone else, the address we control sends a UTXO containing a certain amount of Bitcoin to the other party's address while paying the fees for the transfer. This model is similar to 'sending money' in real life, and UTXOs are like 'unopened envelopes.'
Assuming we are currently using gold transactions, and this gold is very hot, it must be enclosed in an envelope.
Now, Baizi has an unopened envelope containing 20 ounces of gold and wants to pay 10 ounces of gold to Cipher. The transaction action is:
To open this 'unopened envelope containing 20 ounces of gold', you split the gold inside into two, each placed in a separate envelope.
(destroying a UTXO containing 20 BTC, outputting two UTXOs containing 10 BTC each)
You keep one envelope;
(returning a UTXO containing 10 BTC)
You then attach a stamp to the other envelope and send it out;
(paying gas, issuing a UTXO containing 10 BTC)
The courier braves the mountains and rivers to deliver the letter to Cipher.
(miners mine, blocks on the BTC chain, transaction completed)
In the UTXO model, the total amount of gold each person owns is the sum of the gold values in each envelope. Cipher may have hundreds of envelopes containing gold, but they do not automatically open and consolidate into one envelope. In contrast, the 'account model' is the bookkeeping method used by banks, where the amount of gold owned by each person exists as an abstract number. After a transaction is completed, one party's account balance decreases while the other party's balance increases.
In the Bitcoin network, the UTXO model is simpler. This is because, under the UTXO model, a transaction only needs to check whether the historical trace of the received UTXO is correct. In contrast, under the account model, each transaction must check whether both parties' balances are sufficient and update their account statuses. For instance, in real-world physical gold transactions, you only need to burn a piece to prove that a gold bar is genuine, while online transactions require constructing massive data centers to constantly check the status of various accounts to ensure the system operates normally.
Bitcoin Layer Asset Protocol
The so-called layer protocol on Bitcoin hopes to issue a new currency based on Bitcoin, which exists alongside the most stable POW chain and can be used for various new asset play.
For example, let's create a 'gold layer protocol—hamburger coin':
If Baizi wants to issue five hundred 'hamburger coins', he needs to find a real carrier for the hamburger coins, such as five hundred stones engraved with hamburgers, or five hundred sheets of white paper depicting hamburgers. However, stones can wear out and white paper can easily be blown away. As the issuer, Baizi hopes to make the carrier of 'hamburger coins' as stable as possible. At this moment, Baizi thinks of gold, which is durable, fireproof, limited in quantity, and valuable. If hamburgers are painted on gold, that would be quite stable. Thus, Baizi got 500 gold coins, each depicting a hamburger—the issuance of 'hamburger coins' is now complete.
Since 'hamburger coins' are drawn on gold coins, their value includes both the inherent value of gold and the additional value of hamburger information added by Baizi. At the same time, Baizi can create numerous scenarios that large amounts of gold coins cannot enter, such as staking hamburger coins to receive unlimited hamburgers for free. Thus, hamburger coins become a new type of currency with stable carriers, diverse value, and expandable application scenarios, sought after by hamburger enthusiasts.
This method of 'drawing hamburgers on gold coins' is the first layer protocol we will discuss next—colored coins.
II. Early Layer Asset Protocols: Early Attempts at Information Addition
Colored Coins
Colored coins are the earliest layer protocol. By using EPBOC technology to color satoshis, they have become a new currency. After the emergence of OpenAssets technology, they transitioned to coloring UTXOs, requiring historical transaction tracing to ensure the authenticity of the original asset.
To translate into simple terms: originally, Baizi painted hamburgers on gold coins, but later painted hamburgers on the envelopes used for transactions. Since the envelope can only be used once, he must copy the hamburger information from the original envelope onto a new envelope for future transactions. Therefore, to prevent random copying, information about the original before copying must be recorded on the envelope, checking each transaction to see if it can trace back to the earliest hamburger painted by Baizi.
Mastercoin/Omnilayer
Mastercoin wrote color information into the address of the output UTXO, which quickly migrated to Omnilayer, writing color information in OP Return. Furthermore, the previous colored coins and Mastercoin used the UTXO model, while Omnilayer adopted the account model.
What is OP Return? OP Return is a special output where the satoshi being spent is 0. It serves as a descriptor, limiting a transaction to at most one 80-byte OP Return during node broadcasting.
Essence Summary
Thus, we can find that the essence of the layer asset protocol on Bitcoin is to record additional information representing currency in various ways during the transmission process.
Returning to the previous analogy, the essence of the gold layer asset protocol is to represent different ways of drawing hamburgers at each stage of gold and delivery.
This is a very common envelope; if we treat it as a UTXO, in the previously mentioned layer protocol:
Colored coins that color satoshis are hamburgers drawn on the gold coins inside the envelope;
Colored coins that color UTXOs are essentially hamburgers drawn on the envelope;
Mastercoin writes 'Envelope number XXX represents a hamburger' in the recipient's line;
Omnilayer draws hamburgers in the notes section.
Smart friends may already realize that in such protocols, the total places to draw hamburgers are limited to the envelopes and gold; if too much information is to be represented, space runs out. On Bitcoin, such restrictions lead to only simple tokens being issued, while images like NFTs, which require more storage space, cannot be.
III. Engraved Asset Protocol: Breakthrough in Information Addition Technology
From a timeline perspective, the emergence of Ordinals technology is a watershed moment in the history of layer asset protocol development. After the introduction of Ordinals, the information content that can be transmitted in transactions greatly increased through 'engraving.' Next, we will briefly introduce engraving technology and the subsequent engraved asset layer protocols.
Ordinals
Ordinals, or 'ordinal theory,' is the theoretical foundation for the next generation of layer asset protocols. Each satoshi is numbered, and an off-chain indexer is used for retrieval (equipping each grain of gold with a locator to track its flow).
The greatest contribution of Ordinals is the introduction of the 'engraving' method for writing additional information: by entering descriptions for specific satoshis in the 'segregated witness area,' information is bound to satoshis.
Segregated witness is a technology proposed to solve the issue of excessive information included in a single transaction. Simply put, it separates the transaction content and non-transactional 'witness' content, such as private key authorization proofs, from each transaction, allowing miners to verify non-transactional information and submit a receipt to reduce block occupancy.
To explain this in real-world terms:
When sending gold, the courier checks the ID to ensure legal mailing, and after verifying, attaches a label to indicate that verification has been completed, without needing to send a copy of the ID. At this point, there is now more space to draw hamburgers on the label, and we can draw a large crab burger on the label and even have space to write its recipe and preparation method, while also noting 'this crab burger is bound to the leftmost ounce of gold in the envelope.'
Afterward, no matter how this ounce of gold is transferred, we can track that ounce of gold through some kind of numbering tracking system and learn from the records in the label information database that it is a hamburger coin.
On the BTC chain, this 'verified' receipt has a space of about 1M~2M, greatly increasing the amount of information that can be transmitted, and even allowing for image information to be written in. This data remains forever in the transaction history, and the associated satoshis are continuously tracked by indexers.
Since the engraving location is on the 'verified' receipt, engraving must occur after a transaction is issued to obtain the receipt, followed by writing the descriptive information. This process is distinguished as submission (commit) and revelation (reveal) in two steps (wallets typically handle this automatically).
In comparison to early layer asset protocols, Ordinals allow for the issuance of small NFT images on the BTC chain, and transfers and transactions can directly move satoshis without needing secondary engraving.
BRC20/ORC20
These two protocols inherit the engraving scheme of Ordinals but use an account model for balance calculations (Note ③). Under the account model, after receiving the envelope, the gold must be deposited into the account, and all gold in the account is fungible, so when transferring it out, the information must be engraved again. Thus, these two layer protocols adopt the satoshi engraving scheme, requiring engraving for each transfer.
Atomicals/ARC20
The Atomical protocol still follows a two-step engraving process and is specifically designed for fungible tokens based on the UTXO model, allowing direct transfer after creation without needing two operations. The protocol has high playability and allows mining, naming systems, recursive referencing systems, etc.
SRC20
The indexing logic of SRC20 and BRC20 is consistent and is also based on the account model design.
In SRC20, writing additional data does not require the commit/reveal engraving process; it chooses to write binary data into the multi-signature field, creating a high-value UTXO that can never be spent as a 'valuable substitute' for OP Return.
Runes
Runes, which emerged in the first half of this year, represent a return and development of color coin technology, using OP Return as an additional data storage location and employing the UTXO model. The biggest breakthrough is providing flexible minting modes during the minting process, allowing project parties to perform reservations and other operations.
So, are engraved assets the best layer asset solution? Researchers believe not, as this type of asset has a series of common issues.
It heavily relies on a centralized Indexer to index and track satoshis to identify assets; if one day the Indexer server fails, everything will be finished.
This is due to the lack of Turing-complete smart contract capability (unable to develop applications that require looping and recursion, like DEX, IBO, etc.), limiting it to speculation as an investment, unable to play creatively.
Most assets theoretically cannot connect with the Lightning Network—the recognized ultimate solution for BTC—meaning this layer asset protocol is not the ultimate layer protocol.
(This is why there is a 'cross-chain bridge + EVM' paradigm, which uses centralized bridges for pseudo-cross-chain interactions with asset pledge certificates for smart contract interactions.)
Therefore, people have been pursuing a new way to add data that can add large amounts of information without relying on centralized systems, while also being able to creatively use assets and ideally connect with the Lightning Network. This is when the RGB protocol gained attention.
IV. RGB and RGB++: Next-Generation Layer Asset Protocol
RGB: A Breakthrough Traditional Thinking
Before we enter the final part, let's review the earlier conclusion: the essence of Bitcoin's layer asset protocol is to record additional information representing 'this is currency' in various ways during the transmission process of Bitcoin. The reason for choosing the Bitcoin network is to leverage the inherent stability of Bitcoin as a stable carrier for currency.
Is there a way to break free from the existing framework, without directly interacting with Bitcoin itself, without being limited by the writable area on the Bitcoin chain, but still deeply bind with Bitcoin to gain its stability?
With this in mind, developers thought of the RGB concept that took shape as early as 2016. RGB proposed a new path for adding information, and some researchers ranked it alongside the Lightning Network as BTC's ultimate expansion solution.
RGB proposed to achieve state management, asset tracking, and smart contract functionality through technologies such as Single-use-seal and client verification. Is it a bit hard to understand? Let's go step by step:
First, let me introduce Single-use-seal, a core foundational technology of RGB that solves the problem of confirming asset ownership.
In the Bitcoin model, each UTXO can only be spent once, just as each envelope's seal can only be opened once when sending money. Therefore, if we bind the rights to modify an asset's information to the state of a UTXO, we can achieve operations on the asset through address operations on UTXOs—when using a UTXO, we record the changes in asset information in OP Return, completing the changes in asset information.
Unlike colored coins that fully write asset information onto UTXOs, RGB only records changes in asset information on them.
Let's return to the example of hamburger coins—
If Baizi wants to issue five hundred 'hamburger coins', then he needs to find a real carrier for the hamburger coins, such as five hundred stones engraved with hamburgers, or five hundred sheets of white paper with a hamburger picture. However, stones can wear out, and white paper can easily blow away, so as the issuer, Baizi naturally hopes that the carrier of 'hamburger coins' is as stable as possible. At this point, Baizi thinks of gold, which is not easily worn down, fire-resistant, limited in quantity, and very valuable. If hamburgers are painted on gold, that would be quite stable. So, Baizi got 500 gold coins, each with a hamburger painted on it—the issuance of 'hamburger coins' is complete.
Whether it's stones, white paper, or gold, Baizi hopes that hamburger coins can persist. The way RGB achieves this is not by painting hamburgers on gold but by recording the circulating ledger of hamburger coins in the historical flow of gold. Each transaction of hamburger coins leaves a mark on the historical records of gold flow, allowing people thousands of years later to deduce exactly who these 500 hamburger coins belonged to and how they originated in historical flow. Even though there is no direct record on the gold itself, hamburger coins still achieve a shared fate with gold (just like Bitcoin, which gains recognition by replacing real carriers with blockchain ledgers).
If we say that Bitcoin is a ledger, the RGB concept can be understood as creating an 'account within an account' for RGB assets based on the Bitcoin ledger. Specifically, RGB binds each RGB TX to a BTC TX, and each RGB UTXO to a BTC UTXO, thus achieving binding with the Bitcoin chain. Simultaneously, the description of RGB assets is completed off-chain on the Bitcoin chain—there is no need to write asset descriptions onto UTXOs, thus avoiding the constraints of Bitcoin block size, and it can include 'rich states,' meaning it can contain complex asset descriptions, triggering multiple conditions, etc.
However, while the RGB protocol is appealing, its implementation faces many challenges. In the RGB model, the recipient must generate an empty UTXO in advance for asset reception, the sender must provide transaction proof, and the recipient must conduct local verification, lacking globalization and applications. To realize RGB, infrastructure such as DA, P2P networks, virtual machines, and transaction verification needs to be built... Does this sound confusing? No worries, let's return to our happy little hamburger here—
On BTC, we have a complete network for transmission and verification. However, RGB assets only have the assets themselves and must rely on themselves to know their asset status. When Baizi transfers 100 hamburger coins to Cipher, he first must provide proof of previous transfer records to prove he owns the real hamburger coins. Upon receiving, Cipher checks and prepares the UTXO for the next transfer, then approves Baizi's transfer request, completing the transaction, which is obviously too complex.
How to break the deadlock? We need to create a set of asset management systems for RGB assets, allowing RGB assets to be traded and validated on the new system, constructing DA layers, etc.—or directly design RGB assets on a blockchain system with the same architecture as BTC, so that a high-speed public chain can accomplish the necessary work for RGB's implementation and bind it with the BTC network.
The public chain team that realized this is called CKB, and the protocol they designed is called RGB++.
RGB++: Realization and Beyond of RGB
While researching the series of facilities needed for RGB, the CKB team suddenly discovered that the tasks these facilities were designed to perform (such as transaction verification) looked just like the work of a public chain. Why not replace them with a UTXO homomorphic public chain? CKB is a chain with a UTXO model that is homomorphic to BTC—why not use CKB instead???
Based on this idea, CKB proposed 'homomorphic binding technology,' linking Cells (UTXOs in the CKB model) with BTC's UTXOs. Initiating a transaction on A UTXO on-chain serves as the locking condition for A Cell. When a Bitcoin chain transaction is sent out, a CKB chain transaction is also sent simultaneously, and this CKB chain transaction can include new RGB++ assets.
In the RGB++ model, all off-chain data, transaction execution, and verification of Bitcoin occur on the CKB public chain, which possesses Turing-complete smart contract capabilities. RGB++ assets can utilize the dApp infrastructure on the CKB chain. For example, the leading RGB++ asset $Seal can be traded on UTXOswap, and by staking in the IBO platform Seal2earn, users can acquire project airdrops. Thanks to significant optimization in interactivity, the difficulty of deploying RGB++ assets has greatly reduced compared to RGB assets. $Seal has already been listed on Gate Exchange, achieving better liquidity.
At this point, you may be curious why this chapter is titled 'Realization and Beyond of RGB.' We have already understood the realization method, so what does 'beyond' refer to? This is mainly reflected in the programmability and scalability of protocol assets.
In terms of programmability, the RGB protocol relies on UTXOs on BTC. Although it has made some breakthroughs in programmability, it can only support limited smart contracts (like an old game console). In contrast, the RGB++ protocol performs asset mapping through homomorphic binding technology, utilizing the CKB's Turing-complete smart contract capabilities (like a supercomputer), allowing assets to implement recursion, loops, and complex DeFi applications.
In terms of scalability, we must mention another important innovation of the RGB++ protocol, the 'Leap' technology, a cross-chain method that does not require a cross-chain bridge. RGB++ assets are linked to UTXOs on the BTC chain via 'homomorphic binding' for asset management, and the associated objects can actually be any UTXO model chains like CKB, LTC, DOGE, etc. Assets can freely convert among these different chains. Every cross-chain asset transfer is secured by the irreversibility of the UTXO on the source chain. For instance, when Leaping from the BTC chain to the CKB chain, you must wait for six BTC block times before operating the asset; conversely, when Leaping back, you need to wait for 24 CKB block times to achieve the same irreversibility.
RGB++ assets act like a universal key for UTXO chains, which can be inserted into any compatible lock.
Initially, this key is bound to your own house (UTXO on the BTC chain), and you can use a slow old computer at home to browse the web and play flash games (transfer transactions, asset management, etc.). Although the machine is stable, it is quite boring.
One day, you want to play at your friend's house (CKB chain). You do not need to create a new key; you only need to provide some security verification (six BTC block confirmations) to prove you are the true holder of this key (to prevent double-spending attacks), and you can use it to unlock your friend's door and enjoy various new gadgets like the PS5 and Xbox at your friend's house (Turing-complete smart contract capabilities), which is far more fun than your old computer at home.
When you leave your friend's house, the door will require you to perform some verification (24 CKB block confirmations) to ensure nothing unexpected happened before you left. Once the verification is complete, you can leave and safely return to your own home using the same key.
Through the Leap method, RGB++ provides an expansion plan for the UTXO world, laying a solid foundation for multi-chain expansion.
At the end of the third part, we mentioned that the issues with engraved assets mainly revolve around reliance on centralized indexers, lack of Turing-complete smart contract capabilities, and inability to integrate with the Lightning Network. In the RGB++ protocol, the verification mechanism of the CKB chain replaces the tracking of centralized indexers (Note ⑤), provides Turing-complete smart contract capabilities, and CKB itself supports state channels, allowing integration with the Lightning Network. From this perspective, RGB++ is currently the most advanced and excellent solution among the implemented layer asset protocols.
Outlook
The RGB++ protocol was officially released two weeks after this public class, and Cipher deployed the first RGB++ token, $Seal, which is named both as a tribute to the 'Single-use-seal' technology and for its meaning of 'seal.' Just as a seal can thrive in both water and land, Seal can also freely cross chains on BTC and CKB through the Leap technology, affectionately referred to by the community as 'Leopard Coin.'
In April, the Leap function went live, and the concept of cross-chain without bridges entered everyone's sight, breaking the traditional narrative model of 'centralized bridges + EVM.'
In May, various necessary basic infrastructures were launched.
In July, the UTXOswap mainnet and IBO asset issuance platform went live, showcasing the smart contract capabilities brought by the CKB chain.
In August, the Fiber Network light paper was released, and RGB++ assets will become the first type of Bitcoin protocol assets to enter the Lightning Network (refer to Baizi's interpretation article).
At the beginning of this month, the Fiber Network testnet and official website went live. A few days later, at Token2049, CKB will announce more plans to inject new vitality into the market.
I am Hamburger, a proud community Builder, confident in the future of CKB.
Thank you all for your patience in reading. Wishing everyone a happy Mid-Autumn Festival!
Note:
Since the main purpose of this article is to showcase the different forms of layer asset protocols, technical details that are not part of the main storyline will not be expanded upon. Additionally, due to Baizi's own knowledge base and expression ability, some content may have certain deviations. Criticism and corrections from all experts are welcomed.
Besides Segwit blocks, P2TR (Pay to Taproot) also plays a crucial role in the engraving of engraved assets, as the P2TR script path avoids storing data in transaction outputs, thus conserving resources from the UTXO set.
In the UTXO model, the order of input and output satoshis is fixed, so the engraved satoshis can be tracked.
Strictly speaking, BRC20 is not a digital account balance model like ERC20 but resembles a bookkeeping text recorded on the Bitcoin blockchain. It does not possess the functionality of a digital account balance like ERC20. Referring to it as using an account model is not entirely accurate, but is intended to avoid introducing too many concepts.
RGB protocol does not rely on completely recording asset information changes in OP Return; most asset information and complex state changes are handled by off-chain clients. OP Return is merely a way to record the minimum state commitment, without the need to record detailed changes in asset information. This description is intended to simplify understanding and avoid introducing complex concepts like 'commitment.'
The RGB++ protocol and RGB protocol are indeed compatible; users can either verify themselves using a client or allow the CKB chain to verify on their behalf (potentially sacrificing some privacy).
