Satoshi Nakamoto launched the first Bitcoin node on January 3, 2009. New nodes then joined and Bitcoin started behaving like a new life form. A form of life that has continued to evolve since, little by little, to become the safest network in the world. This performance was achieved thanks to its unique design, very well thought out by Satoshi and based on economic incentives. The network attracts users, commonly referred to as miners, who invest in energy and computing power to help keep the network secure.
As Bitcoin continues to grow and adopt, it faces scalability issues. Assuming that the Bitcoin network allows transactions to be mined approximately every 10 minutes, and assuming 144 blocks are mined per day, containing 2,700 transactions each, the network would allow 4.5 transactions per second. As we can read in an email sent to Mike Hearn in March 2011, Satoshi was aware of this limitation. The latter explained the operation of the payment channels that we know today with the Lightning Network. Fast and secure micropayments that do not need to be registered in a network block. This is how protocols intervene off-chain (outside of the Blockchain).
According to Christian Decker, the protocols off-chain are typically systems in which users take data from a blockchain and manage it without touching the blockchain itself, until the last minute. It is on the basis of this concept that the Lightning Network was born, a network that uses protocols off-chain to allow payments in bitcoins to be made almost instantly. Since not all of these operations are written on the blockchain, it allows for thousands of transactions per second to take Bitcoin to scale.
Research and development in the field of protocols off-chain on Bitcoin opened a Pandora’s Box. Today, we know that we can achieve much more than transfer of value, and that, in a decentralized way.
The non-profit association LNP / BP focuses on the development of layer 2 and 3 protocols on Bitcoin and the Lightning Network. Among these projects, RGB stands out.
1. What is RGB?
RGB was born out of Peter Todd’s research on “Single-use-seals” and the “Client-side-validation”. This research was taken from 2016 to 2019 by Giacomo Zucco and the community, to build an asset protocol for Bitcoin and the Lightning Network. This led to the development of RGB, a fully-fledged smart-contract system, designed by Maxim Orlovsky who has been leading its implementation since 2019 with community participation.
We can define RGB as a set of open source protocols that allows us to run smart-contracts complex in an evolving and confidential manner. It is not a particular network (like Bitcoin or Lightning), because each smart-contract only applies to contract participants who can interact using different communication channels (by default the Lightning network). RGB uses the Bitcoin blockchain as a state engagement layer and maintains the code of the smart-contract and the data off-chain. This makes it scalable, as it leverages Bitcoin (and Script) transactions to control ownership of smart-contracts, while their evolution is defined outside the chain. It is important to note that everything is validated on the client side.
Simply put, RGB is a system that allows the user to audit a smart-contract, run it and check it individually at any time without having an additional cost. Indeed, RGB does not use a blockchain like “traditional” systems do. Complex systems of smart-contracts were started by Ethereum but, since they require the user to spend significant amounts of gas for each operation, they never achieved the scalability they promised. Therefore, the latter have never been an option to bank users excluded from the current financial system.
Today, the blockchain industry promotes the idea that the code of smart-contracts and the data must be stored in the blockchain and executed by every node in the network. This without worrying about the excessive increase in size or the misuse of computer resources.
The scheme proposed by RGB is much smarter and more efficient. It breaks with the blockchain paradigm by having smart-contracts and data separated from it. This avoids the saturation seen on other networks, as it does not force every node to perform every contract. The fact that only the parties involved perform the contract also adds a level of confidentiality never seen before.
2. Smart-contracts on RGB
With RGB, the developer of smart-contract defines a scheme specifying the rules for the evolution of this contract over time. The principle of the scheme is the standard for the construction of smart-contracts in RGB, and all parties to the contract must approve it. Both the issuer, when defining the contract for the issue, a Wallet or an exchange platform, must adhere to this particular scheme. It is only if the validation is correct that each party can accept requests and work with the token.
A smart contract on RGB is a “Directed acyclic graph” (DAG) of state changes, where only part of the “Graph” is still known and where there is no access to the rest. The RGB scheme is a set of basic rules for the evolution of this graph with which the smart-contract begin. Each participant in the contract can add elements to these rules (if this is allowed by the diagram) and the graph resulting is built from the repeated application of these rules.
3. The fungible tokens
(not to be confused with the non-fungible tokens, or NFT, of part 5)
Fungible tokens on RGB follow the LNPBP RGB-20 specification. When an RGB-20 is defined, the token data called “Genesis data”, are distributed by the Lightning network. This data contains what is necessary to use the token. The most basic form of token does not allow secondary issuance, the token burn, renomination or replacement.
Sometimes the issuer will need to issue more tokens in the future. This is particularly the case with stablecoins like USDT, which keep the value of each token linked to the value of an inflationary currency like the USD. To achieve this, there are more complex RGB-20 schematics which, in addition to genesis data, require the transmitter to produce consignments, which will also circulate in the Lightning network. This information will allow us to know the total supply of this active asset. The same goes for the token burn or change of name.
Information about the asset can be public or private. If the issuer requires confidentiality, it can choose not to share the information on the token and to carry out transactions in complete confidentiality. On the other hand, we also have the opposite case in which the issuer and the holders need the whole process to be transparent. To do this, you have to share the token data.
4. The RGB-20 procedures
The procedure burn disable them tokens and these cannot be used afterwards.
The replacement procedure takes place when the tokens are “burned” and that a new quantity of the same token is created. This helps reduce the size of the asset’s historical data, which is important to maintain its speed.
To take care of the case where it is possible to “burn” tokens without having to replace them, a sub-scheme of the RGB-20 is used to allow only this token burn.
5. Non-fungible tokens (NFT)
Non-fungible tokens in RGB follow the LNPBP RGB-21 specification. When we work with NFTs, we also have a main schema and a sub-schema. These schemas have an burn procedure, which allows the token owner to attach custom data. The most common example we see in NFTs today is the digital artwork related to the token.
The token issuer can prohibit the burning of this data using the RGB-21 sub-scheme. Unlike other NFT blockchain systems, RGB is used to distribute tokens with large media data in a completely decentralized and censorship resistant way. RGB uses an extension of the P2P Lightning network called Bifrost, which is also used to construct many other forms of smart contracts specific to RGB.
Besides the fungible tokens and the NFT, RGB and Bifrost can also be used to produce other forms of smart contracts like DEXs, liquidity pools, Stablecoins algorithmic, etc.
6.NFT from RGB vs NFT from other networks
- No expensive storage built into a blockchain.
- No need for 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 plays this role.
- There is no need to trust websites for managing data related to NFT tokens, issued assets or ABIs of contracts.
- Built-in DRM encryption and ownership management.
- Infrastructure for backups using the Lightning Network (Bifrost).
- Ways to monetize content (not just selling the NFT itself, but accessing the content, multiple times)
Since the launch of Bitcoin almost 13 years ago, there has been a lot of research and experimentation in the field. The successes and mistakes have given us a little better understanding of how decentralized systems behave in practice, what makes them truly decentralized, and what actions tend to lead them to centralization. All of this has led us to conclude that real decentralization is difficult to achieve. The actual decentralization has only been achieved by Bitcoin and it is for this reason that we are focusing our efforts to build on top of its protocol.
RGB has its own “rabbit hole” inside Bitcoin’s. I venture there and I will post what I learn there. In the next article, I will talk about LNP and RGB nodes and explain how to use them.