RGB in theory

Introduction to smart contracts and their states

RGB programming

Introduction to smart contracts and their states

Smart contracts and digital bearer rights
Introduction to Smart Contract RGB status
Status and Business Logic in RGB
Contract Operations: creation and evolution of the State
Operations chain: from Genesis to Terminal State
Summary

In this and the next chapter, we'll look at the notion of smart contract within the RGB environment and explore the different ways in which these contracts can define and evolve their state. We'll see why the RGB architecture, using the ordered sequence of Single-use Seals, makes it possible to execute various types of Contract Operations in a scalable way and without going through a centralized registry. We'll also look at the fundamental role of Business Logic in framing the evolution of the contract state.

Smart contracts and digital bearer rights

RGB's aim is to provide an infrastructure for implementing smart contracts on Bitcoin. By "smart contract" we mean an agreement between several parties that is automatically and computationally enforced, without human intervention to enforce the clauses. In other words, the law of the contract is enforced by the software, not by a trusted third party.

This automation raises the question of decentralization: how can we free ourselves from a centralized registry (e.g. a central platform or database) to manage ownership and contract performance? The original idea, taken up by RGB, is to return to a mode of ownership known as "bearer instruments". Historically, certain securities (bonds, shares, etc.) were issued in bearer form, enabling anyone who physically possessed the document to enforce his or her rights.

RGB applies this concept to the digital world: rights (and obligations) are encapsulated in data that is manipulated off-chain, and the status of this data is validated by the participants themselves. This allows, a priori, a much greater degree of confidentiality and independence than that offered by other approaches based on public registers.

Introduction to Smart Contract RGB status

A smart contract in RGB can be seen as a state machine, defined by:

A State, i.e. the set of information reflecting the current configuration of the contract;
A Business Logic (set of rules), which describes under what conditions and by whom the state can be modified.

It's important to understand that these contracts are not limited to the simple transfer of tokens. They can embody a wide variety of applications: from traditional assets (tokens, stocks, bonds) to more complex mechanics (usage rights, commercial terms, etc.). Unlike other blockchains, where the contract code is accessible and executable by all, RGB's approach compartmentalizes access and knowledge of the contract to participants ("contract participants"). There are several roles:

The issuer or creator of the contract, who defines the Genesis of the contract and its initial variables;
Parties with rights (ownership) or other enforcement capabilities;
Observers, potentially limited to seeing certain information, but who cannot trigger modifications.

This separation of roles contributes to censorship resistance, by ensuring that only authorized persons can interact with the contractual state. It also gives RGB the ability to scale horizontally: the majority of validations take place outside the blockchain, and only cryptographic anchors (the commitments) are inscribed on Bitcoin.

Status and Business Logic in RGB

From a practical point of view, the contract's Business Logic takes the form of rules and scripts, defined in what RGB calls a Schema. The Schema encodes:

State structure (which fields are public? Which fields are owned by which parties)?
Validity conditions (what must be checked before authorizing a state update?);
Authorizations (who can initiate a State Transition? Who can only observe?).

At the same time, the Contract State often breaks down into two components:

A Global State: public part, potentially observable by all (depending on configuration);
Owned States: private parts, allocated specifically to owners via UTXOs referenced in the contract logic.

As we'll see in the following chapters, any status update (Contract Operation) must dock to a Bitcoin commitment (via Opret or Tapret) and comply with the Business Logic scripts to be considered valid.

Contract Operations: creation and evolution of the State

In the RGB universe, a Contract Operation is any event that changes the contract from a old state to a new state. These operations follow the following logic:

We take note of the current status of the contract;
We apply the rule or operation (a State Transition, a Genesis if it's the very first state, or a State Extension if there's a public valency to re-trigger);
We anchor the modification via a new commitment on the blockchain, closing one single-use seal and creating another;
The rights holders concerned validate locally (client-side) that the transition conforms to the Schema and that the associated Bitcoin transaction is registered on-chain.

The end result is an updated contract, now with a different state. This transition does not require the entire Bitcoin network to be concerned with the details, since only a small cryptographic fingerprint (the commitment) is recorded in the blockchain. The sequence of Single-use Seals prevents any double-spending or double-use of the State.

Operations chain: from Genesis to Terminal State

To put this into perspective, an RGB smart contract starts with a Genesis, the very first state. Thereafter, various Contract Operations follow one another, forming a DAG (Directed Acyclic Graph) of operations:

Each transition is based on a previous state (or several, in the case of convergent transitions);
The chronological order is guaranteed by the inclusion of each transition in a Bitcoin anchor, time-stamped and unalterable thanks to consensus by Proof-of-Work;
When no more operations are in progress, a Terminal State is reached: the most recent and complete state of the contract.

This DAG topology (instead of a simple linear chain) reflects the possibility that different parts of the contract may evolve in parallel, as long as they do not contradict each other. RGB then takes care of avoiding any inconsistencies by client-side verification of each participant involved.

Summary

Smart contracts in RGB introduce a model of digital bearer instruments, decentralized but anchored in Bitcoin for time-stamping and guaranteeing the order of transactions. Automated execution of these contracts is based on:

A Contract State, indicating the current configuration of the contract (rights, balances, variables, etc.);
A Business Logic (Schema), defining which transitions are allowed and how they must be validated;
Contract Operations, which update this state step by step, thanks to commitments anchored in Bitcoin transactions.

In the next chapter, we'll go into more detail about the concrete representation of these states and state transitions at the off-chain level, and how they relate to the UTXOs and Single-use Seals embedded in Bitcoin. This will be an opportunity to see how RGB's internal mechanics, based on client-side validation, manage to maintain the consistency of smart contracts while preserving data confidentiality.

Quiz

csv4022.3

1/5

What operations define the evolution of a smart contract in RGB?