Progress pill
RGB in theory

Introduction to distributed computing concepts

RGB programming

Introduction to distributed computing concepts

  • Introduction
  • Trilemmas in distributed computing
  • The role of blockchain and the notion of sharding
  • The notion of state transitions
  • The stash concept
  • Single-use Seal: origins and operation
  • Multiple commitments and roots
  • Questions from the public
  • Conclusion
RGB is a protocol designed to apply and enforce digital rights (in the form of contracts and assets) in a scalable and confidential way, based on the consensus rules and operations of the Bitcoin blockchain. The aim of this first chapter is to present the basic concepts and terminology around the RGB protocol, highlighting in particular its close links with basic distributed computing concepts such as Client-side Validation and Single-use Seals.
In this chapter, we explore the fundamentals of distributed consensus systems and see how RGB fits into this family of technologies. We'll also introduce the main principles that help us understand why RGB aims to be extensible and independent of Bitcoin's own consensus mechanism, while relying on it when necessary.

Introduction

Distributed computing, a specific branch of computer science, studies the protocols used to circulate and process information on a network of nodes. Together, these nodes and the protocol rules constitute what is known as a distributed system. Among the essential properties that characterize such a system , some are:
  • The capability of independent verification and validation of certain data by each node;
  • The possibility for nodes to construct (depending on the protocol) a complete or partial view of the information. These views are the states of the distributed system;
  • The chronological order of operations, so that data is reliably time-stamped and there is a consensus on the sequence of events (sequence of states).
In particular, the notion of consensus in a distributed system covers two aspects:
  • Recognition of the validity of state changes (according to protocol rules);
  • The agreement on the order of these state changes, which makes it impossible to rewrite or reverse validated operations a posteriori (this is also known in Bitcoin as "double-spend protection").
The first functional, permission-free implementation of a distributed consensus mechanism was introduced by Satoshi Nakamoto with Bitcoin, thanks to the combined use of a blockchain data structure and a Proof-of-Work (PoW) algorithm. In this system, the credibility of the block history depends on the computing power devoted to it by the nodes (miners). Bitcoin is therefore a major and historic example of a distributed consensus system open to all (permissionless).
In the world of blockchain and distributed computing, we can distinguish two fundamental paradigms: blockchain in the traditional sense, and state channels, the best example of which in production is the Lightning Network. The blockchain is defined as a register of chronologically ordered events, replicated by consensus within an open, permission-free network. State channels, on the other hand, are peer-to-peer channels that enable two (or more) participants to maintain an updated state off-chain, using the blockchain only when opening and closing these channels.
In the context of Bitcoin, you're no doubt familiar with the principles of mining, decentralization and finality of transactions on the blockchain, as well as how payment channels work. With RGB, we're introducing a new paradigm called Client-side Validation, which, unlike blockchain or Lightning, consists in locally (client-side) storing and validating the state transitions of a smart contract. This also differs from other "DeFi" techniques (rollups, plasma, ARK, etc.), where the Client-side Validation relies on the blockchain to prevent double-spending and to have a time-stamping system, while keeping the register of off-chain states and transitions, only with the participants concerned.
Later on, we'll also introduce an important term: the notion of "stash", which refers to the set of client-side data required to preserve the state of a contract, as this data is not replicated globally across the network. Finally, we'll look at the rationale behind RGB, a protocol that takes advantage of Client-side Validation, and why it complements existing approaches (blockchain and state channels).

Trilemmas in distributed computing

To understand how Client-side Validation and RGB address problems not solved by blockchain and Lightning, let's discover 3 major "trilemmas" in distributed computing:
  • Scalability, Decentralization, Privacy;
  • CAP Theorem (Consistency, Availability, Partition Tolerance);
  • CIA trilemma (Confidentiality, Integrity, Availability).

1. Scalability, decentralization and confidentiality

  • Blockchain (Bitcoin)
Blockchain is highly decentralized, but not very scalable. What's more, since everything is in a global, public register, confidentiality is limited. We can try to improve confidentiality with zero-knowledge technologies (confidential transactions, mimblewimble schemes, etc.), but the public chain cannot hide the transaction graph.
  • Lightning/State channels
State channels (as with the Lightning Network) are more scalable and more private than blockchain, as transactions take place off-chain. However, the obligation to publicly announce certain elements (funding transactions, network topology) and the monitoring of network traffic can partly compromise confidentiality. Decentralization also suffers: routing is cash-intensive, and major nodes can become centralization points. This is precisely the phenomenon we're beginning to see on Lightning.
  • Client-side Validation (RGB)
This new paradigm is even more scalable and more confidential, because not only can we integrate zero-disclosure proof-of-knowledge techniques, but there is no global graph of transactions, since nobody holds the entire register. On the other hand, it also implies a certain compromise on decentralization: the issuer of a smart contract can have a central role (like a "contract deployer" in Ethereum). However, unlike blockchain, with Client-side Validation, you only store and validate the contracts you're interested in, which improves scalability by avoiding the need to download and verify all existing states.

2. CAP Theorem (Consistency, Availability, Partition tolerance)

The CAP theorem emphasizes that it is impossible for a distributed system to simultaneously satisfy Consistency,Availability and Partition tolerance.
  • Blockchain
The blockchain favors consistency and availability, but doesn't do well with network partitioning: if you can't see a block, you can't act and have the same view as the whole network.
  • Lightning
A system of state channels has availability and partitioning tolerance (since two nodes can remain connected to each other even if the network is fragmented), but overall consistency depends on the opening and closing of channels on the blockchain.
  • Client-side Validation (RGB)
A system like RGB offers consistency (each participant validates its data locally, without ambiguity) and partitioning tolerance (you keep your data autonomously), but does not guarantee global availability (everyone has to make sure they have the relevant pieces of history, and some participants may not publish anything or stop sharing certain information).

3. CIA trilemma (Confidentiality, Integrity, Availability)

This trilemma reminds us that confidentiality, integrity and availability cannot all be optimized at the same time. Blockchain, Lightning and Client-side Validation fall differently into this balance. The idea is that no single system can provide everything; it is necessary to combine several approaches (blockchain's time-stamping, Lightning's synchronous approach, and local validation with RGB) to obtain a coherent package offering good guarantees in each dimension.

The role of blockchain and the notion of sharding

The blockchain (in this case, Bitcoin) serves primarily as a time-stamping mechanism and protection against double spending. Instead of inserting the complete data of a smart contract or decentralized system, we simply include cryptographic commitments to transactions (in the sense of Client-side Validation, which we'll call "state transitions"). Thus:
  • We free the blockchain from a large amount of data and logic;
  • Each user stores only the history required for his own portion of the contract (his "shard"), rather than replicating the global state.
Sharding is a concept that originated in distributed databases (e.g. MySQL for social networks such as Facebook or Twitter). To solve the problem of data volume and synchronization latencies, the database is segmented into shards (USA, Europe, Asia, etc.). Each segment is locally consistent and only partially synchronized with the others.
For RGB-type smart contracts, we shard according to the contracts themselves. Each contract is an independent shard. For example, if you only hold USDT tokens, you don't have to store or validate the entire history of another token like USDC. On Bitcoin, the blockchain doesn't do sharding: you have a global set of UTXOs. With Client-side Validation, each participant retains only the contract data it holds or uses.
We can therefore imagine the ecosystem as follows:
  • The blockchain (Bitcoin) as a foundation that ensures complete replication of a minimal register and serves as a time-stamping layer;
  • The Lightning Network for fast, confidential transactions, still based on the security and final settlement of the Bitcoin blockchain;
  • RGB and Client-side Validation to add more complex smart contract logic, without cluttering up the blockchain or losing confidentiality.
These three elements form a triangular whole, rather than a linear stack of "layer 2", "layer 3" and so on. Lightning can connect directly to Bitcoin, or be associated with Bitcoin transactions that incorporate RGB data. Similarly, a "BiFi" (finance on Bitcoin) can compose with the blockchain, with Lightning and with RGB according to needs for confidentiality, scalability or contract logic.

The notion of state transitions

In any distributed system, the aim of the validation mechanism is to be able to determine the validity and chronological order of state changes. The aim is to verify that the protocol rules have been respected, and to prove that these state changes follow one another in a definitive, unassailable order.
To understand how this validation works in the context of Bitcoin and, more generally, to grasp the philosophy behind Client-side Validation, let's first take a look back at the mechanisms of the Bitcoin blockchain, before seeing how Client-side Validation differs from them and what optimizations it makes possible.
In the case of the Bitcoin blockchain, transaction validation is based on a simple rule:
  • All network nodes download every block and transaction;
  • They validate these transactions to verify the correct evolution of the UTXO set (all unspent outputs);
  • They store this data (in the form of blocks) so that the history can be replayed if necessary.
However, this model has two major drawbacks:
  • Scalability: since each node must process, verify and archive everyone's transactions, there is an obvious limit to transaction capacity, linked in particular to the maximum block size (1 MB on average over 10 minutes for Bitcoin, excluding cookies);
  • Privacy: everything is broadcast and stored publicly (amounts, destination addresses, etc.), which limits the confidentiality of exchanges.
In practice, this model works for Bitcoin as a base layer (Layer 1), but may become insufficient for more complex uses that simultaneously require high transaction throughput and a certain degree of confidentiality.
Client-side Validation is based on the opposite idea: rather than requiring the entire network to validate and store all transactions, each participant (client) will validate only the part of the history that concerns him or her:
  • When a person receives an asset (or any other digital property), they only need to know and verify the chain of operations (state transitions) that lead to that asset and prove its legitimacy;
  • This sequence of operations, from the Genesis (initial issue) to the most recent transaction, forms an acyclic directed graph (DAG) or shard, i.e. a fraction of the overall history.
At the same time, so that the rest of the network (or more precisely, the underlying layer, such as Bitcoin) can lock in the final state without seeing the details of this data, Client-side Validation relies on the notion of commitment.
A commitment is a cryptographic commitment, typically a hash (SHA-256 for example) inserted into a Bitcoin transaction, which proves that private data has been included, without revealing this data.
Thanks to these commitments, we can prove:
  • The existence of information (since it is committed to a hash);
  • The anteriority of this information (because it is anchored and time-stamped in the blockchain, with a date and block order).
The exact content, however, is not revealed, thus preserving its confidentiality.
In concrete terms, here's how an RGB state transition works:
  • You prepare a new state transition (e.g. the transfer of an RGB token);
  • You generate a cryptographic commitment to this transition and insert it into a Bitcoin transaction (these commitments are called "anchors" in the RGB protocol);
  • The counterparty (the recipient) retrieves the customer-side history associated with this asset and validates end-to-end consistency, from the genesis of the smart contract to the transition you transmit to it.
Client-side Validation offers two major benefits:
  • Scalability:
The commitments included in the blockchain are small (of the order of a few dozen bytes). This ensures that block space is not saturated, as only the hash needs to be included. It also enables the off-chain protocol to evolve, as each user only has to store his or her history fragment (his or her stash).
  • Privacy:
Transactions themselves (i.e. their detailed content) are not published on-chain. Only their fingerprints (hash) are. Thus, amounts, addresses and contract logic remain private, and the receiver can verify, locally, the validity of his shard by inspecting all previous transitions. There is no reason for the receiver to make this data public, except in the event of a dispute or where proof is required.
In a system like RGB, multiple state transitions from different contracts (or different assets) can be aggregated into a single Bitcoin transaction via a single commitment. This mechanism establishes a deterministic, time-stamped link between the on-chain transaction and the off-chain data (the client-side validated transitions), and enables multiple shards to be simultaneously recorded in a single anchor point, further reducing the on-chain cost and footprint.
In practice, when this Bitcoin transaction is validated, it permanently "locks" the state of the underlying contracts, since it becomes impossible to modify the hash already inscribed in the blockchain.

The stash concept

A stash is the set of client-side data that a participant must absolutely retain to maintain the integrity and history of an RGB smart contract. Unlike a Lightning channel, where certain states can be reconstructed locally from shared information, the stash of an RGB contract is not replicated elsewhere: if you lose it, no one will be able to restore it to you, as you are responsible for your share of the history. This is why you need to adopt a system with reliable backup procedures in RGB.

Single-use Seal: origins and operation

When accepting an asset such as a currency, two guarantees are essential:
  • The authenticity of the item received;
  • The uniqueness of the item received, to avoid double expenses.
For physical assets, such as a banknote, physical presence is enough to prove that it has not been duplicated. However, in the digital world, where assets are purely informational, this verification is more complex, as information can easily multiply and be duplicated.
As we saw earlier, the sender's revelation of the history of state transitions enables us to ensure the authenticity of an RGB token. By having access to all transactions since the genesis transaction, we can confirm the token's authenticity. This principle is similar to that of Bitcoin, where the history of coins can be traced back to the original coinbase transaction to verify their validity. However, unlike Bitcoin, this history of state transitions in RGB is private and kept on the client side.
To prevent double-spending of RGB tokens, we use a mechanism called "Single-use Seal". This system ensures that each token, once used, cannot be fraudulently reused a second time.
Single-use Seals are cryptographic primitives, proposed in 2016 by Peter Todd, akin to the concept of physical seals: once a seal has been placed on a container, it becomes impossible to open or modify it without irreversibly breaking the seal.
This approach, transposed to the digital world, makes it possible to prove that a sequence of events has indeed taken place, and that it can no longer be altered a posteriori. Single-use Seals thus go beyond the simple logic of hash + timestamp, adding the notion of a seal that can be closed only once.
For Single-use Seals to work, you need a publication proof medium capable of proving the existence or absence of a publication, and difficult (if not impossible) to falsify once the information has been disseminated. A blockchain (like Bitcoin) can fill this role, as can a paper newspaper with a public circulation do, as an example. The idea is as follows:
  • We want to prove that a certain commitment on a message h(m) has been published to an audience without revealing the content of the message m;
  • We want to prove that no other competing h(m') message commitment has been published in place of h(m);
  • We also want to be able to check that message m exists before a certain date.
A blockchain lends itself ideally to this role: as soon as a transaction is included in a block, the whole network has the same unfalsifiable proof of its existence and content (at least in part, since the commitment can hide the details while proving the authenticity of the message).
A Single-use Seal can therefore be seen as a formal promise to publish a message (still unknown at this stage) once and only once, in a way that can be verified by all interested parties.
Unlike simple commitments (hash) or timestamps, which attest to a date of existence, a Single-use Seal offers the additional guarantee that no alternative commitment can coexist: you can't close the same seal twice, or attempt to replace the sealed message.
The following comparison helps to understand this principle:
  • Cryptographic commitment (hash): With a hash function, you can commit to a piece of data (a number) by publishing its hash. The data remains secret until you reveal the pre-image, but you can prove that you knew it in advance;
  • Timestamp (blockchain): By inserting this hash in the blockchain, we also prove that we knew it at a precise moment (that of inclusion in a block);
  • Single-use Seal: With single-use seals, we go one step further by making the commitment unique. With a single hash, you can create several contradictory commitments in parallel (the problem of the doctor who announces "It's a boy" to the family and "It's a girl" in his personal diary). The Single-use Seal eliminates this possibility by connecting the commitment to a proof-of-publication medium, such as the Bitcoin blockchain, so that an expenditure of UTXO definitively seals the commitment. Once spent, the same UTXO cannot be re-spent to replace the commitment.
Simple commitment (digest/hash)TimestampsSingle-use seals
Publishing the commitment does not reveal the messageYesYesYes
Proof of the commitment date / existence of the message before a certain dateImpossiblePossiblePossible
Proof that no alternative commitment can existImpossibleImpossiblePossible
Single-use Seals work in three main stages:
Seal Definition:
  • Alice defines in advance the rules for publishing the seal (when, where and how the message will be published);
  • Bob accepts or acknowledges these conditions.
Seal Closing:
  • At runtime, Alice closes the seal by publishing the actual message (usually in the form of a commitment, e.g. a hash);
  • It also provides a witness (cryptographic proof) proving that the seal is closed and irrevocable.
Seal Verification:
  • Once the seal is closed, Bob can no longer open it: he can only check that it has been closed;
  • Bob collects the seal, the witness and the message (or his commitment) to make sure that everything matches and that there are no competing seals or different versions.
The process can be summarized as follows:
# Defined by Alice, validated or accepted by Bob
seal <- Define()
# Seal is closed by Alice with the message
witness <- Close(seal, message)
# Verification by Bob
bool <- Verify(seal, witness, message)
Client-side validation, however, goes one step further: if the definition of a seal itself remains outside the blockchain, it is possible (in theory) for someone to challenge the existence or legitimacy of the seal in question. To overcome this problem, a chain of interlocking Single-use Seals is used:
  • Each closed seal contains the definition of the following seal;
  • We register these closures (with their commitments) within the blockchain (in a Bitcoin transaction);
  • Thus, any attempt to modify a previous seal would contradict the history embedded in Bitcoin.
This is precisely what the RGB system does:
  • Published messages are commitments to client-side validated data;
  • The seal definition is associated with a Bitcoin UTXO;
  • The seal closes when this UTXO is spent or when a new output is credited to the same commitment;
  • The transaction chain that spends these UTXOs corresponds to the proof of publication: every transition or change of state on RGB is thus anchored in Bitcoin.
To sum up:
  • The seal definition is the UTXO you intend to seal a future commitment;
  • The seal closing occurs when you spend this UTXO, creating a transaction that contains the commitment;
  • The witness is the transaction itself, which proves that you have closed the seal with this content;
  • You can't prove that a seal hasn't been closed (you can't be absolutely sure that a UTXO hasn't already been spent or won't be spent in a block you haven't seen yet), but you can prove that it has indeed been closed.
This uniqueness is important for Client-side Validation: when you validate a state transition, you check that it corresponds to a unique UTXO, not previously spent in a competing commitment. This is what guarantees the absence of double spending in off-chain smart contracts.

Multiple commitments and roots

An RGB smart contract may need to spend several Single-use Seals (several UTXOs) simultaneously. What's more, a single Bitcoin transaction may reference several distinct contracts, each sealing its own state transition. This requires a multi-commitment mechanism to prove, deterministically and uniquely, that none of the commitments exists in duplicate. This is where the notion of anchor comes into play in RGB: a special structure linking a Bitcoin transaction and one or more client-side commitments (state transitions), each potentially belonging to a different contract. We'll take a closer look at this concept in the next chapter.
Two of the project's main GitHub repositories (under the LNPBP organization) group together the basic implementations of these concepts studied in the first chapter:
  • client_side_validation: Contains Rust primitives for local validation;
  • single_use_seals: Implements the logic to define and close these seals securely.
Note that these software bricks are Bitcoin agnostic; in theory, they could be applied to any other proof-of-publication medium (another registry, a journal, etc.). In practice, RGB relies on Bitcoin for its robustness and broad consensus.

Questions from the public

Towards wider use of Single-use Seals

Peter Todd also created the Open Timestamps protocol, and the Single-use Seal concept is a natural extension of these ideas. Beyond RGB, other use cases can be envisaged, such as the construction of sidechains without resorting to merge mining or drivechain-related proposals like BIP300. Any system requiring a single commitment can, in principle, exploit this cryptographic primitive. Today, RGB is the first major full-scale implementation.

Data availability problems

Since in Client-side Validation, each user stores his or her own part of the history, data availability is not guaranteed globally. If a contract issuer withholds or revokes certain information, you may be unaware of the actual evolution of the offer. In some cases (such as stablecoins), the issuer is expected to maintain public data to prove the volume in circulation, but there is no technical obligation to do so. It is therefore possible to design deliberately opaque contracts with unlimited supply, which raises questions of trust.

Sharding and contract isolation

Each contract represents an isolated shard: USDT and USDC, for example, do not have to share their histories. Atomic swaps are still possible, but this does not involve merging their registers. Everything is done by cryptographic commitment, without disclosing the entire history graph to each participant.

Conclusion

We've seen where the concept of Client-side Validation fits in with blockchain and state channels, how it responds to distributed computing trilemmas, and how it leverages the Bitcoin blockchain uniquely to avoid double-spending and for time-stamping. The idea is based on the notion of Single-use Seal, enabling the creation of unique commitments that you can't re-spend at will. In this way, each participant uploads only the history that is strictly necessary, increasing the scalability and confidentiality of smart contracts while retaining the security of Bitcoin as a backdrop.
The next step will be to explain in more detail how this Single-use Seal mechanism is applied in Bitcoin (via UTXOs), how anchors are created and validated, and then how complete smart contracts are built in RGB. In particular, we'll look at the issue of multiple commitments, the technical challenge of proving that a Bitcoin transaction simultaneously seals multiple state transitions in different contracts, without introducing vulnerabilities or double commitments.
Before diving into the more technical details of the second chapter, feel free to reread the key definitions (Client-side Validation, Single-use Seal, anchors, etc.) and keep in mind the overall logic: we're looking to reconcile the strengths of the Bitcoin blockchain (security, decentralization, time-stamping) with those of off-chain solutions (speed, confidentiality, scalability), and this is precisely what RGB and Client-side Validation are trying to achieve.
Quiz
Quiz1/5
How does RGB improve scalability compared with traditional blockchain?