A Brief Introduction To RGB Protocols

RGB protocols promise to enable complex smart contracts that operate on top of Bitcoin and Lightning.

On January 3, 2009, Satoshi Nakamoto launched the first Bitcoin node. From that moment, new nodes joined and Bitcoin began to behave as if it were a new form of life, a form of life that has not stopped evolving. Little by little, it has become the safest network in the world as a result of its unique design — very well thought out by Satoshi — because, through economic incentives, it attracts users, commonly called miners, to invest in energy and computing power which contributes to network security.

As Bitcoin continues its growth and adoption, it faces scalability issues. The Bitcoin network allows a new block with transactions to be mined in approximately 10 minutes. Assuming we have 144 blocks in a day with maximum values ​​of 2,700 transactions per block, Bitcoin would have allowed only 4.5 transactions per second. Satoshi was aware of this limitation, we can see it in an email sent to Mike Hearn in March 2011 where he explains how what we know today as a payment channel works. This is where off-chain protocols come in.

According to Christian Decker, off-chain protocols are usually systems in which users use data from a blockchain and manage it without touching the blockchain itself until the last minute. Based on this concept, the Lightning Network was born, a network that uses off-chain protocols to allow Bitcoin payments to be made almost instantaneously. Since not all these operations are written on the blockchain, it allows thousands of transactions per second and scales Bitcoin.

Research and development in the area of ​​off-chain protocols on Bitcoin has opened a Pandora’s box. Today we know that we can achieve much more than value transfer in a decentralized way, the nonprofit LNP/BP Standards Association focuses on development of Layer 2 and 3 protocols on Bitcoin and the Lightning Network. Among these projects, RGB stands out.

What Is RGB?

RGB was based on research by Peter Todd on single-use seals and client-side validation and envisioned in 2016 by Giacomo Zucco as a better asset protocol for Bitcoin and the Lightning Network. Further evolution of these ideas led to the development of RGB into a fully-fledged smart contract system by Maxim Orlovsky, who is leading its implementation since 2019 with community participation.

We can define RGB as a set of open-source protocols that allows us to execute complex smart contracts in a scalable and confidential way. It is not a particular network (like Bitcoin or Lightning); each smart contract is just a set of contract participants which can interact using different communication channels (defaulting to the Lightning Network). RGB uses the Bitcoin blockchain as a layer of state commitment and maintains the code of the smart contract and the data off-chain, which makes it scalable. By leveraging Bitcoin transactions (and Script) as an ownership control system for smart contracts, the evolution of the smart contract is defined by an off-chain scheme. It is important to note that everything is validated on the client side.

In simple terms, RGB is a system that allows the user to audit a smart contract, execute it and verify it individually at any time without an additional cost since it does not use a blockchain as “traditional” systems do. While complex smart contract systems were pioneered by Ethereum, it requires the user to spend significant amounts of gas for each operation and it never achieved the scalability it promised. By consequence, Ethereum never was an option to bank the users excluded from the current financial system.

Currently, the blockchain industry promotes that both the code of smart contracts and the data must be stored in the blockchain and executed by each node of the network, regardless of the excessive increase in size or the misuse of computational resources. The scheme proposed by RGB is much more intelligent and efficient since it cuts with this blockchain paradigm by having smart contracts and data separated from the blockchain and thus avoids the saturation of the network seen in other platforms. In turn, RGB does not force each node to execute each contract but rather the parties involved which adds confidentiality to a level never seen before.

Smart Contracts In RGB

In RGB, a smart contract developer defines a schema specifying rules on how the contract evolves over time. The schema is the standard for the construction of smart contracts in RGB: Both an issuer when defining a contract and a wallet or exchange must adhere to a particular scheme against which they must validate the contract. Only if the validation is correct can each party accept requests and work with the asset.

A smart contract in RGB is a directed acyclic graph (DAG) of state changes, where only a portion of the graph is always known and there is no access to the rest. The RGB scheme is a core set of rules for the evolution of this graph that the smart contract starts with. Each contract participant may add to those rules (if this is allowed by the schema) and the resulting graph is built from the iterative application of those rules.

Fungible Assets

The fungible assets in RGB follow the LNP/BP RGB-20 specification. So, when an RGB-20 is defined, the asset data known as “genesis data” is distributed through the Lightning Network, which contains what is required to use the asset. The most basic form of assets do not allow secondary issuance, token burning, renomination or replacement.

Sometimes the issuer will need to issue more tokens in the future, such as stablecoins such as USDT, which keeps the value of each token tied to the value of an inflationary currency such as the USD. To achieve this, more complex RGB-20 schemata exist, and in addition to the genesis data, they require the issuer to produce consignments, which will be also circulating in the Lightning Network. With this information, we can know the total circulating supply of the asset. The same applies for burning assets or changing its name.

The information related to the asset can be public or private: If the issuer requires confidentiality, they can choose not to share information about the token and perform operations in absolute privacy, but we also have the opposite case in which the issuer and the holders need the whole process to be transparent. This is achieved by sharing the token data.

RGB-20 Procedures

The burning procedure disables tokens and burned tokens can’t be used anymore. The replacement procedure occurs when tokens are burned and a new amount of the same token is created. This helps reduce the size of the asset’s historical data, which is important to maintain asset speed. To support the use case where it is possible to burn assets without having to replace them, a subschema of RGB-20 is used that only allows burning assets.

Non-Fungible Tokens

The non-fungible tokens (NFTs) in RGB follow the LNP/BP RGB-21 specification, when we work with NFTs we also have a main schema and a subschema. These schemata have an engraving procedure, which allows us to attach custom data by the token owner. The most common example we see in NFTs today is digital art linked to the token. The token issuer can prohibit this data engraving by using the RGB-21 subschema. Unlike other NFT blockchain systems, RGB allows the distribution of large-size media token data in a completely decentralized and censorship-resistant manner, utilizing an extension to the Lightning P2P Network called Bifrost, which is also used for building many other forms of RGB-specific smart contract functionalities.

Additionally to fungible assets and NFTs, RGB and Bifrost can be used to produce other forms of smart contracts, including decentralized exchanges (DEXes), liquidity pools, algorithmic stable coins, and more, which we will cover in future articles.

NFT From RGB Versus NFT From Other Platforms

• No need for expensive blockchain storage.
• No need for the InterPlanetary File System (IPFS), a Lightning Network extension (called Bifrost) is used instead (and it’s fully end-to-end encrypted).
• No need for a special data management solution (again, Bifrost takes that role).
• No need to trust websites to maintain data for NFT tokens or about issuer’s assets or contract ABIs.
• RGB has built-in DRM encryption and ownership management.
• RGB has infrastructure for backups using the Lightning Network (Bifrost).
• RGB has ways to monetize content (not only selling the NFT itself, but access to the content, several times).

Conclusions

Since the launch of Bitcoin, almost 13 years ago, there has been a lot of research and experimentation in the area. Both the successes and the mistakes have allowed us to understand a little more how decentralized systems behave in practice, what makes them really decentralized and what actions tend to lead them to centralization. All this has led us to conclude that real decentralization is a rare and difficult phenomenon to achieve; real decentralization has only been achieved by Bitcoin and it is for this reason that we focus our efforts to build on top of it.

RGB has its own rabbit hole within the Bitcoin rabbit hole. While I am falling down through them both, I will post what I have learned. In the next article, we will have an introduction to the LNP and RGB nodes and how to use them.

This is a guest post by Francisco Calderón. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.