RGB

logo-
Use RGB
Github Telegram X-twitter

Design

Overview of the main concepts and features of the RGB design

Single-use seals

Physical single-use seals are uniquely numbered plastic ties commonly used to detect tampering during storage and shipment, so for example once you close a single-use-seal around the door of a shipping container, if you find the seal with the expected identifier printed on it still intact you can be quite sure that nobody opened the container during shipping (assuming it is sufficiently hard to manufacture an indistinguishable copy of such seal).

Similarly, with digital single-use seals (first proposed by Peter Todd in 2016), it is possible to close a digital seal over a message to make sure that the message can be used only once. As an example, let’s say that the message is the certificate of ownership of a property, without a single-use-seal system I could show such certificate to multiple people and convince each one of them that I have sufficient right to the property to sell it to them. By applying a single-use-seal to the certificate, we can define the act of opening the seal as a necessary step to sell the property, in this way it is impossible to seller to attempt to sell twice the same property without the second buyer noticing that the property was already sold in the past as the digital seal is no longer intact.

A simple way to implement digital single-use seal is to have a notary service that keeps track and certifies on a publicly accessible registry each time a seal is closed or opened, so that anyone can verify the state of a seal they are interested in. However this setup requires trust towards the notary service, and therefore it is not applicable for protocols that attempt to be trustless and censorship-resistant.

Bitcoin-based single-use seals

Instead of using a trusted entity to certify the opening and closing of digital seals, it is possible to use Bitcoin’s Unspent Transaction Outputs (UTXOs) as seals. An UTXO indeed can be seen as a seal that is closed when it is created, and opened when it is spent. Due to Bitcoin consensus rules, an output can be spent only once, therefore, if used as a seal, the same set of incentives that enforce Bitcoin consensus rules will guarantee that the seal can be opened only once.

To provide a more practical example, let’s imagine there is an ownership certificate that defines as clause necessary to transfer ownership to a new party the need to spend a specific Bitcoin UTXO (whose private key should be controlled by the same owning party), and when such UTXO is spent, in the spending Bitcoin transaction it is indicated who will be the new owner of the transferred property. Since Bitcoin data structures are deliberately constrained by strict rules, it would be a bit limiting to have to encode all the information about the receiving party inside the Bitcoin transaction itself (other than being very bad for the privacy of the parties involved), so a better approach is to add to the Bitcoin transaction only a commitment to who the receiver is (e.g. a hash of the receiver’s UTXO in the output field).

Each time the ownership is transferred, we are effectively creating an amendment to the original contract, specifying which is the new Bitcoin UTXO that is now in control of the ownership.

Notice that the Bitcoin transactions are not connected to each other, the ownership is "teleported" from one UTXO to the other without leaving a trace in the Bitcoin transaction graph

RGB state transitions

RGB uses the above described Bitcoin-based single-use-seal model, meaning that when an RGB transaction occurs, what actually happens is that the sender creates a state transition of the contract defining the rights being transferred. Let’s take the case of fungible assets. First, the issuer of a contract sets the genesis state which defines the contract details, such as asset name, total supply and UTXO with the right to move the supply. Then, as the assets are first transferred, the owner of the first UTXO can create a state transition that defines which new UTXO will now own the asset.

State transitions can be applied to the right to change ownership of the asset, but also to other kinds of rights, for example, in the context of asset issuance, it can be the right to do a secondary issuance, or the right to add/change certain properties of the asset (e.g. the metadata).

Validation

Validation of incoming transfers in RGB is significantly different from how it works with normal Bitcoin payments. In Bitcoin, a node connected to the network continuously downloads and validates blocks and mempool transactions. In this way, it is able to have always an updated view of the UTXO set (the collection of all unspent outputs on the blockchain), and when it sees a new transaction, to check the validity of its history it only needs to verify that all the inputs are part of the last state of the UTXO set.

In RGB there is no global network where all the transactions are being broadcast that can be used to create the equivalent of Bitcoin UTXO set. This means that while receiving an incoming payment, an RGB client not only has to verify that the last state transition is valid, but also needs to do the same validation for all previous state transitions up the genesis state in the issuance contract.

At the same time this also means that, differently from Bitcoin and any other global consensus systems, in RGB a client does not need to see and validate all the transactions happening globally, as it has to be aware only of those relevant to its wallet. As a consequence, there is much less burden for each client on the amount of data they need to validate, causing the overall system to be more scalable.

The need for an RGB client to validate a lot of data at the same time upon receiving a payment can be seen as a problem, as it can result in a slow payment experience due to the validation time needed to consider an incoming transfer as valid. However this becomes a problem only when you start having assets with a very long transaction history, and by that time new data availability layers can be built, to allow clients to voluntarily share with each other state transition data related to specific contracts, so that future receivers can start validating part of the transaction history in advance.

Deterministic Bitcoin Commitments

RGB leverages the Bitcoin blockchain for protection from double spending, and this is achieved by committing each RGB state transition inside the Bitcoin transaction spending the UTXO that owns the rights being moved. To make the commitment both versatile and secure, two conditions must be met: (i) multiple state transitions can be committed in a single Bitcoin transaction and (ii) each state transition can be committed only once in the Bitcoin transaction (otherwise double spending would be possible).

To enable having several state transitions in one commitment, the state transitions are aggregated multiple times: first all the state transitions related to a specific contract (or asset ID) are deterministically aggregated, then all the commitments of all assets being moved are aggregated in a merkle tree and the resulting top hash is the final RGB commitment. To ensure compatibility with other protocols unrelated to RGB that may also need to use Deterministic Bitcoin Commitments, a further aggregation is conducted between the RGB commitment and the commitment from other protocols (as described by the LNPBP-4 standard), with the resulting hash being the message effectively getting inserted into the Bitcoin transaction.

Once there is the final LNPBP-4 message ready, there are two ways to commit it into the Bitcoin transaction:

  1.  

    Taproot commitment: an OP_RETURN script containing the LNPBP-4 message is added in the top right leaf of the TapTree of the first Taproot output of the Bitcoin transaction, and it will be revealed only off-chain to the receiver of the RGB transfer. In this way the Bitcoin transaction can contain only one taproot output that can be used for both sending the bitcoin change back to the sender and to contain the commitment without adding any extra byte and without leaving any mark that the Bitcoin transaction may contain an RGB commitment.

  2.  

    OP_RETURN commitment: the LNPBP-4 message is inserted directly into the first OP_RETURN output of the Bitcoin transaction. This results in 46 extra bytes in the transaction, but it does not reveal any information about the content of the RGB transfer as to the blockchain observer it is just an OP_RETURN with a hash (exactly like, for example, open timestamp transactions). The advantage of this scheme over the Taproot based one is its simplicity and easier implementation for wallet developers.

In case multiple commitments are inserted into the Bitcoin transaction, only the first one will be relevant for RGB validation rules, and the others will be ignored, making any attempt to double spend pointless.

 

Batching

Due to the fact that it is possible to include an arbitrary amount of state transitions in a single Bitcoin commitment, large batching operations are possible. If for example someone wants to pay multiple people at the same time, he can just create a state transition for every receiver and commit all of them to the same Bitcoin transaction, without increasing it by a single extra byte. This means that the marginal on-chain fee cost per RGB payment can become very small as the same fee is shared by an arbitrary large amount of transfers.

However, the batching is effective only when spending from the same UTXO, as if a user is spending from multiple UTXOs each of those outputs have to be included as input in the Bitcoin transaction, making its size and the on-chain fee it needs to pay grow. This means that batching is particularly useful for service providers with consolidated UTXOs such as exchanges operating withdrawals to a lot of users. For example an exchange could aggregate all the withdrawal requests every 30 minutes, and with the cost of a single Bitcoin transaction with one input and one output pay every user that sent a withdrawal request in that time-frame.

 

Privacy

RGB already benefits from a high degree of privacy thanks to the client-side validation design which hides information from blockchain observers, but to further improve it other features have been added to the protocol.

 

Blinded UTXOs

To have the receiver of a transfer gain extra privacy from the payer RGB uses blinded UTXOs as payment outpoints instead of plain UTXOs. This means that when a user wants to be paid, instead of sharing the UTXO where he wants to receive the assets, he will share it in a blinded format which consists in the hash of the concatenation between the UTXO and a random blinding secret. In this way, the payer does not know exactly where the assets went, and he cannot monitor when they will be spent in the future (which is something that the payer can always do with regular Bitcoin on-chain payments).

To prove during the spending phase that his UTXO is indeed the owner of certain assets, the sender needs to share with the receiver the blinding secret used to generate the blinded UTXO, so that during the validation phase it can be verified that the blinded UTXO that received the asset has been derived from the UTXO that is spending them.

Example of blinded UTXO:

UTXO: ad3ebdcda0f83b37fffab0439c89fd3ef7d99c41c353a45a98d5983d9ad00183:0

Outpoint blinding secret: 8114079862469528952

Blinded outpoint: txob1kewrvnf8sjmarq65gv98lz2xrgxylpnlta8lc3p78fjxaw9qda4qkewlwr


Client to client communications

For an RGB transfer to be successful, the clients involved need to share with each other some data. Specifically, the sender needs to share with the receiver(s) the consignment, which is a data structure containing all the information needed to validate the transfer, including all the history of previous state transitions up the genesis contract.

RGB is agnostic about the communication channel used for this data sharing operation, and it can happen in many different ways. While potentially it would be possible to share consignment data even via pigeon carriers, more practical digital communication channels have been implemented in RGB software. Currently, there are two main ways to share data in RGB:

  •  

    Storm: a p2p messaging and storage system built over the Lightning Network.

  •  

    RGB proxy server: a standardised HTTP JSON-RPC server where clients can upload and download data. A user can run his own proxy server, or use the server of a third party. Relying on a third party server has privacy and censorship implications, but not security ones.

The coordination over the choice of the communication channel to use happens over an invoice protocol, where the receiver provides one or more endpoints where the sender can upload the consignment data.