EagleEye is a Web3 B2C platform that allows users to analyze projects, addresses, risks, and relationships between projects. The platform can also help users monitor the projects and SmartMoney addresses they are interested in. EagleEye’s goal is to help Web3 users

Find α (alpha), Avoid Scam.

About the author: EagleEye community researcher — Alpha Hunter

wenshuang (Twitter Handle: @shuang_log2pi);

Eaton (Twitter Handle: @EatonAshton2);

Understanding the RGB Protocol in one sentence: Its function is to add smart contract capabilities to Bitcoin over the Lightning Network through a zero-knowledge proof-based state channel protocol, enabling users to conduct privacy-protected transactions off-chain.

RGB is not a token protocol, but it possesses the capability to issue and manage a variety of highly scalable, programmable, and confidential assets. It can play a significant role in many industries beyond finance.

1. Development of the RGB Protocol

— 2016: Giacomo Zucco, inspired by Peter Todd’s ideas, initially conceptualized the RGB Protocol.

— 2017: BHB Network launched the original version of the RGB Protocol, supported by the Poseidon Group.

— 2019: Maxim Orlovsky and Giacomo Zucco established the LNP/BP Standards Association to advance RGB towards practical application. Dr. Maxim Orlovsky began redesigning the RGB Protocol.

— 2021: The Association demonstrated RGB’s Turing-complete virtual machine (AluVM), and RGB started operating on the Lightning Network.

— 2022: Introduced a new language, Contractum, for writing RGB smart contracts for Bitcoin and the Lightning Network, along with its new website.

— April 2023: Released RGB v0.10, bringing full smart contract support to Bitcoin and the Lightning Network, marking a significant development phase for the RGB Protocol (Download & Install RGB v0.10: https://rgb.tech, Source Code: https://github.com/RGB-WG).

2. Design Logic of the RGB Protocol

The core idea of the RGB Protocol revolves around consensus and off-chain data storage.

The primary value in distributed systems is maintaining consensus. Using the Bitcoin consensus layer, only short cryptographic commitments to ledger events are retained. These commitments, typically implemented via hash functions, prove the existence of specific data without revealing its contents. Storing these commitments on-chain ensures data authenticity and integrity while reducing the burden on the blockchain.

RGB’s ledger data is stored off-chain, meaning all contract data and state transitions are kept off-chain rather than on the blockchain. By utilizing single-use seals and state transitions, RGB efficiently tracks and verifies the status of smart contracts without storing all data on-chain, thereby effectively processing and validating the states and transactions of smart contracts.

The foundational layer of the RGB protocol is the Bitcoin blockchain, encompassing Nakamoto PoW consensus and the transaction ledger. While it does not require storing any data on the chain, it still follows existing infrastructure, utilizing Bitcoin transactions as a repository for these commitments. This is achieved by building on the Bitcoin protocol layer, establishing a foundation for client-side validation.

2.1 Client-Side Validation

In the client-side validation model of RGB smart contracts, all data is kept outside of Bitcoin transactions, such as the Bitcoin blockchain or Lightning Network channel states. This system operates over the Lightning Network, providing a basis for higher-level protocol scalability and privacy.

2.2 RGB Smart Contracts

The basic components of RGB smart contracts include Genesis (creation), State, and Transitions, each serving different functions and roles:

- Genesis

Genesis is the initial declaration of a smart contract, defining its basic attributes and rules, including contract type, purpose, and any initial settings. In the code, the genesis part sets the starting point of the contract, such as specifying initial identity information in an identity verification contract.

- State

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

- Transitions

Transitions define the rules for transitioning from one state to another. These rules determine how states change according to contract logic. Examples of transitions include op Revocation and op Transfer, which define how to move from one Identity state to another or transfer between tokens.

These three components offer a way to define and execute various operations and protocols. Genesis sets foundational rules and parameters, State maintains current contract information, and Transitions dictate the logic for state changes, forming the core architecture of RGB smart contracts.

2.3 Single-Use Seals

To ensure secure and efficient asset transfer management while protecting user privacy, the RGB protocol uses the “single-use-seals” method. This approach binds assets (like tokens) to a specific Bitcoin transaction output, requiring each asset transfer to “open” an old seal and “create” a new one. Single-use seals represent asset ownership or contract states. Each state transition or transaction closes the related seal and creates a new one, ensuring transaction security by preventing asset reuse or double spending and guaranteeing immutability in asset transfers.

Since these operations occur client-side rather than being stored entirely on the blockchain, they significantly enhance user privacy protection, reduce blockchain space usage, and improve overall network efficiency and scalability.

Steps of single-use-seals:

1. Each RGB contract begins with a genesis operation, defining initial states and related single-use seals, representing the initial distribution of assets or rights defined in the contract.

2. In the contract, States are used to represent the current configuration of assets or rights. Each state is associated with a single-use seal, representing current ownership or rights.

3. Transitions involve moving or changing assets or rights. This process includes closing the current single-use seal (representing the old state) and creating a new seal (representing the new state).

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

5. During transactions, contract participants need to verify the related single-use seals for legitimacy. This verification is automated, carried out by RGB nodes and participating wallets.

3. Establishing RGB Lightning Network Channels

The process of creating RGB Lightning Network channels, from a payment principle perspective, involves the following steps:

1. Channel Creation

To create a payment channel between two nodes, Bitcoin is initially required. For instance, on Umbrel (which allows users to run a Bitcoin and Lightning Network node), users can click on the Bitcoin tab in the dashboard, select deposit, and then send Bitcoin to their Umbrel node’s Bitcoin address. Once the node is funded, users can start creating channels.

The creation of the channel is peer-to-peer. For example, if users A and B wish to create a 10btc payment channel, they each contribute 5btc (though the amount each contributes to the channel can vary). The specific process involves A and B using their respective UTXOs (UTXO-A and UTXO-B) as inputs, jointly signing a transaction that goes on-chain and outputs UTXO-AB. Then, A generates an off-chain transaction TX-A1 and gets B to sign it. Subsequently, B generates an off-chain transaction TX-B1 and gets A to sign it.

2. Multi-Signature Contract

The core of the channel is a 2-of-2 multi-signature contract, where both parties hold Bitcoin. Although from the blockchain’s perspective, these BTC are jointly owned, each party has a portion of it and retains a record of this ownership locally.

3. Transaction Execution

Within the channel, payments are made between the multi-signature contracts. Each channel represents a UTXO (Unspent Transaction Output) on the Bitcoin blockchain and is jointly controlled by two peer nodes. They can transact within the channel.

4. Off-Chain Transactions

Through these channels, users can execute an unlimited number of transactions off-chain, significantly reducing transaction costs while leveraging the security of the Bitcoin network.

4. Interaction of RGB Protocol with Wallets

The key to the RGB protocol lies in how it interacts with users’ wallets to support complex transactions and contract operations. Below is a detailed explanation of these steps and their importance in the overall transaction process, based on disclosures from its technical documentation.

Initial Preparation

The wallet needs to prepare a special Bitcoin transaction draft, known as a PSBT (Partially Signed Bitcoin Transaction), which is like drafting a contract outlining the basic framework of the transaction.

Sending Information to RGB Node

The wallet sends information involved in the transaction draft (like which Bitcoins are spent) to the RGB node, a server specifically handling RGB contracts. The RGB node prepares a record containing all historical information of the spent Bitcoins, akin to packing a folder with all relevant historical records.

Organizing New Transactions

Based on this record, the wallet organizes new transactions, specifying recipients and change addresses (if necessary). This is similar to filling out specific recipient and payment details in a traditional draft contract.

Final Preparation by RGB Node

The RGB node completes the final preparation of this record and prepares a document called a disclosure. This disclosure contains information about other contracts that may be affected by this operation. This step ensures that all relevant files and records are prepared before completing the transaction.

Signing and Publishing

Once the process is complete, the transaction record is sent to the recipient (beneficiary), who must sign off on the transfer. After receiving the signature, the Bitcoin transaction signing process is completed, and it is published on the Bitcoin network. Simultaneously, the RGB node updates its internal records to reflect the latest status of the smart contract.

The entire process resembles a complex transaction involving detailed record preparation, multiple signatures, and final confirmation and publication. The RGB protocol ensures secure transactions of smart contracts in this manner.

5. Applications of the RGB Protocol

Financial Applications:

1. Creating tokens representing shares of companies or projects, issued centrally but traded in a decentralized manner, enhancing market liquidity and transparency.

2. Managing loans and bonds through automated lending and bond issuance and repayment via smart contracts.

3. Creating stablecoins operating on the Lightning Network, usable as a medium of payment.

4. Developing decentralized exchanges (DEX).

5. Implementing solutions like algorithmically over-collateralized stablecoins and other AMM solutions to provide market liquidity and stability.

Non-Financial Applications:

1. Managing self-sovereign identity solutions, enabling individuals to control and manage their digital identity information.

2. Establishing a decentralized global name registration system for registering and managing domain names and other internet identifiers.

3. Managing digital content ownership and licensing, including copyrights and licenses.

4. Tokenizing artworks, offering a new digital ownership and trading platform for artists and collectors.

5. Managing DAOs (Decentralized Autonomous Organizations) to achieve decentralized decision-making and governance.

6. Creating provable and verifiable audit log systems to enhance the transparency and credibility of enterprises and projects.

6. Code Features of the RGB Protocol

The code features of the RGB protocol showcase its innovation in smart contracts. Here are some key points:

1. Schema Concept

The RGB protocol adopts the concept of Schema, similar to the class concept in object-oriented programming. Schemas define standards for RGB assets, facilitating support by wallets, exchanges, browsers, and BTC nodes. In this framework, a specific RGB contract is an instance of a schema, created by the schema’s constructor (“genesis operation”). This method separates the roles of contract developers (schema developers) and issuers, allowing the latter to operate without programming or security expertise.

2. AluVM Virtual Machine

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

3. Contract Definition Example

RGB uses specific data types like PgpKey in contract definitions. These types are not direct parts of the contract but can be shared across multiple contracts. Contract states and operations, like Identity and Revocation, are defined as parts of the contract state and possible state transitions.

4. Contract Instances and State Transitions

Contract instantiation involves applying a schema to specific cases, like meSatoshiNakamoto implementing the DecentralizedIdentity schema, defining initial states, and assigning them to single-use seals. State transitions, like through a Revocation operation, involve updating identities and assigning them to new single-use seals.

5. Extending Contract Functions

RGB allows for extending contract functions, like adding IOU (I Owe You) tokens, represented in the contract as an ownable state IOYTokens. Additionally, there are global states like IOYTicker and IOYName, which are global attributes of the contract, not directly owned by any party.

6. Special Syntax Structures

The distinction between global state and ownable state in contracts is that the global state applies to the entire contract, while the ownable state is associated with specific single-use seals. Contracts also use special syntax structures like braces, brackets, and question marks to denote sets or arrays of data types involved in state operations and their optionality.

7. Concept of State Extensions

The concept of state extensions allows the public to participate in specific logical parts of the contract, such as declaring a Burn. State extension operations allow anyone to create state extensions without on-chain commitments, similar to Bitcoin transactions not yet packaged into a block.

8. Contract Interface

— Standardized Communication: The contract interface provides a standard way to communicate with RGB nodes, requiring them to return semantically meaningful states and create operations.

— Similar to Ethereum’s ERC Standards: These interfaces are similar to Ethereum’s ERC standards. Generic interfaces are called “RGBxx” and are defined as independent LNP/BP standards.

9. Example of Creating a Generic Token Interface

— Interface Definition: Defines global states (like Ticker and Name) and ownable states (like Inflation and Asset), along with operations (like Issue and Transfer).

— Interface Implementation: When implementing an interface, states and operations of a specific schema are bound to the interface. For example, the FungibleToken interface implements global and ownable state bindings for the DecentralizedIdentity schema.

The RGB protocol, with its unique schema definitions, AluVM virtual machine, flexible contract state management, and extension mechanisms, demonstrates its innovation in the field of BTC smart contracts. For more details, refer to RGB Protocol GitHub: https://github.com/RGB-WG/blackpaper/tree/master.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram LinkedIn