Analyze the design and characteristics of the RGB protocol and the security challenges it faces

In the second half of 2023, the ecosystem of various BTC derivative protocols will develop rapidly. In addition to the resurgence of the Ordinals protocol and BRC20, protocols such as Atomicals and Taproot Assets have also received widespread attention from the market.

Previously, Beosin has analyzed the risks of several types of BTC derivative protocols: “The explosion of the BTC ecosystem, analyzing the potential opportunities and risks of its various derivative protocols”. **In this article, Beosin will explain in detail a very important asset issuance protocol in the BTC ecosystem - RGB protocol. **

1. RGB Protocol Development

The role of the RGB protocol is to add smart contract functionality to Bitcoin on the Lightning Network, a zero-knowledge proof-based state channel protocol that allows users to conduct privacy-preserving transactions off-chain. **

RGB is not a token protocol, but it has the ability to issue and manage multiple highly scalable, programmable, and confidential assets, and may play an important role in many other industries outside of finance. The development of its protocol has gone through several important phases, from its initial conception to the current RGB v0.10 version that brings smart contract functionality to Bitcoin and the Lightning Network.

1 In 2016, Giacomo Zucco proposed the initial idea of the RGB protocol based on the ideas of Peter Todd.

2 In 2017, BHB Network launched the original version of the RGB protocol, which was supported by the Poseidon Group.

3 In 2019, Maxim Orlovsky and Giacomo Zucco founded the LNP/BP Standards Association to promote RGB for practical applications, and Dr. Maxim Orlovsky began redesigning the RGB protocol.

4 In 2021, the association demonstrated the Turing-Complete Virtual Machine (AluVM) of the RGB protocol, which also began to run on the Lightning Network.

5. In 2022, Contractum, a new language for writing RGB smart contracts for Bitcoin and Lightning Network, was launched, and its new website.

6. In April 2023, RGB v0.10 was released, bringing full support for smart contracts to Bitcoin and the Lightning Network, marking the most important stage of development for the RGB protocol.

2. RGB protocol design logic

The core idea of the RGB protocol is built around consensus and off-chain data storage.

First of all, the most important value of the distributed system is the maintenance of consensus, using the bit consensus layer only needs to keep short cryptographic commitments to the ledger events, the technology of proving the existence of specific data but not revealing the actual data content, usually implemented through the hash function, only storing these submissions on the chain to ensure the authenticity and integrity of the data, thereby reducing the burden of on-chain data.

Ledger data by RGB is stored off-chain, which means that all contract data and state transitions remain off-chain, not on the blockchain. Track and verify the state of smart contracts with single-use seals and state transitions, efficiently processing and verifying the state and transactions of smart contracts without storing all data on-chain.

The base layer of RGB is the Bitcoin blockchain, including the Nakamoto PoW consensus and transaction ledger. While there is no need to store any data on-chain, there is still a need to follow the existing infrastructure and utilize Bitcoin transactions as storage for these commitments.

2.1 Client Authentication

RGB smart contracts in client-side verification mode, where all data will remain outside of Bitcoin transactions, such as the Bitcoin blockchain or Lightning network channel state, enabling the system to operate on top of the Lightning Network and also providing the foundation for a high level of protocol scalability and privacy.

2.2 RGB Smart Contract

The basic structure of an RGB smart contract consists of Genesis, State, and Transitions, each of which has different functions and roles:

Genesis(创世)

Genesis is the initialization declaration of a smart contract, which defines the basic properties and rules of the contract. This includes the type of contract, its purpose, and any initial settings. In the code, the genesis part defines the starting point of the contract, such as in an authentication contract, which can specify the initial identity information.

State（状态）

State represents the current state of the contract at any given moment in time, and is a real-time snapshot of the contract data, including all variable values and asset information.

Transitions(转换)

Transitions are rules that define transitions from one state to another. These rules determine how the state changes based on the contract logic. op Vocation and op Transfer are examples of transformations that define how to transfer from one Identity state to another, or how to transfer between tokens.

These three components provide a way to define and execute various operations and protocols. Genesis sets the underlying rules and parameters, State maintains the current information of the contract, and Transitions stipulates the logic of changes between states, which together form the core architecture of the RGB smart contract.

2.3 一次性密封(single-use-seals)

To ensure secure and efficient management of asset transfers while protecting user privacy. The RGB protocol uses a “single-use-seals” approach, which allows assets (such as tokens) to be tied to a specific transaction output of Bitcoin, such that each asset transfer requires “opening” an old seal and “creating” a new one. **One-time encapsulation is used to represent the ownership or contract status of an asset. Each time a state transfer or transaction occurs, the associated encapsulation is closed and a new encapsule is created, which has the advantage that each seal can only be used once, thus preventing the reuse or double payment of assets, ensuring the security of the transaction and thus ensuring that the transfer of assets cannot be tampered with.

At the same time, because these operations are carried out on the client side instead of being all stored on the blockchain, the privacy protection of users is greatly enhanced, and the occupation of blockchain space is reduced, improving the efficiency and scalability of the overall network.

Logical steps for single-use-seals:

1. The beginning of each RGB contract is a genesis operation, where the initial state and the associated one-time encapsulation are defined, representing the initial allocation of assets or permissions defined in the contract.

2. In the contract, the state is used to represent the current asset or permission configuration. Each status is associated with a one-time encapsulation that represents current ownership or permissions.

3. When it is necessary to transfer or change assets or permissions, there are transitions of state involved. This process involves closing the current one-time encapsulation (representing the old state) and creating a new encapsulation (representing the new state).

4. Closing a package involves verifying its integrity and marking it as used to prevent reuse. Then, based on the contract rules, a new encapsulation is created to represent the new state.

5. When a transaction occurs, contract participants need to verify that the relevant one-time encapsulation is valid to ensure the legitimacy of the transaction. This verification process is automatic and is done collaboratively by RGB nodes and participating wallets.

3. Characteristics of RGB protocol

The characteristics of RGB are reflected in the innovation of RGB smart contracts, and the following are some key points for you:

1. Schema Concept

The RGB protocol uses the concept of a schema, similar to classes in object-oriented programming. Modes are used to define standards for RGB assets**, making it easy for wallets, exchanges, browsers, and BTC nodes to support RGB assets. In this framework, a concrete RGB contract is an instance of a pattern, created by the schema’s constructor (the “genesis operation”). This approach separates the roles of the contract developer (pattern developer) and the contract issuer, eliminating the need for the latter to have programming or security knowledge.

2. AluVM Virtual Machine

The RGB protocol also introduces the AluVM virtual machine, a Turing-complete virtual machine similar to Ethereum’s EVM. It can perform almost all types of calculations, but is limited by the number of operation steps. AluVM limits computation through a cumulative measure of computational complexity, similar to Ethereum’s gas consumption mechanism.

3. Example of Contract Definition

In terms of contract definition, the RGB protocol uses specific data types, such as PgpKey, which are not a direct part of the contract but can be shared by multiple contracts. The state and actions of a contract, such as Identity and Revocation, are defined as components of the state of the contract and possible state transitions.

4. Contract Instances and State Transitions

Contract instantiation is done by applying a pattern to a specific situation, for example, meSatoshiNakamoto implements the DecentralizedIdentity pattern, which defines the initial state and assigns it to a one-time seal. State transitions, such as through the Vocation operation, involve updating an identity and assigning it to a new one-time seal.

5. Extended Contract Functionality

The RGB protocol allows to extend the functionality of the contract, such as adding IOU (I owe you) tokens, which are represented as ownable states in the contract, IOYTokens. In addition, there are global states, such as IOYTicker and IOYName, which are global properties of the contract and are not directly owned by any party.

6. The Concept of State Extension

The concept of state extensions allows the public to participate in specific logical parts of the contract, such as by declaring Burn. The state expansion operation allows anyone to create a state extension without making an on-chain commitment, similar to a Bitcoin transaction that is not encapsulated in a block.

7. 合约接口（Contract Interface）

Standardized communication: The contract interface provides a standard way to communicate with an RGB node, requiring it to return a semantically meaningful state and create operations.

Similar to Ethereum’s ERC standard: These interfaces are similar to Ethereum’s ERC standard, and the generic interface is called “RGBxx” and is defined as a stand-alone LNP/BP standard.

8. Example of Creating a Universal Token Interface

Interface Definitions: Defines global states (e.g., Ticker and Name) and owned states (e.g., Inflation and Asset), as well as operations (e.g., Issues and Transfers).

Interface implementation: When an interface is implemented, the state and operation of a specific mode are bound to the interface. For example, the FungibleToken interface implements global and owned state bindings for the DecentralizedIdentity pattern.

4. RGB protocol application

Financial Applications:

1 Used to create tokens that represent shares in a company or project, issued centrally but traded in a decentralized manner, increasing market liquidity and transparency.

2. Manage loans and bonds, and automate loan and bond issuance and repayment through smart contracts.

3. Create stablecoins that run on the Lightning Network and use these stablecoins as a means of payment.

4. Create a decentralized exchange (DEX).

5. Apply AMM solutions such as algorithmically over-collateralized stablecoins to provide liquidity and stability to the market.

Non-financial applications:

1. Used to manage self-contained identity solutions that enable individuals to control and manage their digital identity information.

2. Create a decentralized global name registration system so that people can register and manage domain names and other web identifiers.

3. Manage ownership and licensing rights for digital content, including copyrights and licenses.

4. Used to tokenize artworks, providing a new digital ownership and trading platform for artists and collectors.

5. Manage DAOs for decentralized decision-making and governance.

6. Used to create a provable and verifiable audit log system to increase transparency and credibility of businesses and projects.

5. Risks of the current RGB protocol

1 Instability

The current RGB protocol is the first version to fully support smart contracts, and there may be some major updates or modifications to the RGB protocol in the future, which will cause the current development of the contract to not run safely and stably in subsequent versions. RGB’s client validator is still being updated, and there is no stable version yet.

2 Complexity

The design and implementation of the RGB protocol is quite complex, and there are many features of the RGB protocol that need to be considered for smart contracts developed based on the RGB protocol. For example, if the tokens issued based on the RGB protocol fail or are not confirmed by the RGB node, then these tokens do not belong to any UTXO and are equivalent to being burned, and developers and project parties need to carefully consider the impact of such situations on the project’s token economy.

Summary

The RGB protocol is still in its very early stages. The RGB protocol has demonstrated its innovation in the field of BTC smart contracts through its unique schema definition, AluVM virtual machine, flexible contract state management and scaling mechanism, supporting the issuance and transfer of multiple assets on the Bitcoin network and the Lightning network. However, at present, the RGB protocol is not fully compatible with the Lightning Network, and the development and operation of smart contracts are not secure, so users need to be aware of the risks when using the RGB protocol. **