RGB Docs
  • RGB Protocol Documentation
  • Distributed Computing Concepts
    • Paradigms of Distributed Computing
    • Client-side Validation
    • Single-use Seals and Proof of Publication
  • Commitment layer
    • Commitment Schemes within Bitcoin and RGB
    • Deterministic Bitcoin Commitments - DBC
      • Opret
      • Tapret
    • Multi Protocol Commitments - MPC
    • Anchors
  • RGB State and Operations
    • Introduction to Smart Contracts and their States
    • Contract Operations
    • Components of a Contract Operation
    • Features of RGB State
  • RGB Contract Implementation
    • Schema
      • Schema example: Non-Inflatable Assets
  • RGB over Lightning Network
    • Lightning Network compatibility
  • Annexes
    • Glossary
    • Contract Transfers
    • Invoices
    • RGB Library Map
Powered by GitBook
On this page
  • Anchor
  • AluVM
  • Assignment
  • Business Logic
  • Client-side Validation
  • Commitment
  • Consignment
  • Contract
  • Contract Operation
  • Contract Participant
  • Contract Rights
  • Contract State
  • Deterministic Bitcoin Commitment - DBC
  • Directed Acyclic Graph - DAG
  • Extra Transaction Proof - ETP
  • Genesis
  • Invoice
  • Global State
  • Lightning Network
  • Multi Protocol Commitment - MPC
  • Owned State
  • Ownership
  • Partially Signed Bitcoin Transaction - PSBT
  • Schema
  • Seal Definition
  • Shard
  • Single-Use Seal
  • Stash
  • State Transition
  • Taproot
  • Transition Bundle
  • UTXO
  • Witness Transaction
  1. Annexes

Glossary

Terminology used in RGB sorted in alphabetical order

PreviousLightning Network compatibilityNextContract Transfers

Last updated 26 days ago

Anchor

Set of client-side data that proves the inclusion of a unique inside a transaction. In RGB protocol it is constituted by:

  • The Bitcoin transaction ID of the .

  • The Multi Protocol Commitment - .

  • The Deterministic Bitcoin Commitment - .

  • The in the case of commitment scheme.

AluVM

Acronym of Algorithmic logic unit Virtual Machine, it is a register-based virtual machine for smart contract validation and distributed computing, used but not limited to RGB contract validation.

Assignment

The RGB-equivalent of a transaction output modifying, updating or creating some properties of the state of a . It is formed by:

  • A

  • An

Business Logic

Client-side Validation

Commitment

The commitment is required to possess two fundamental security properties:

Consignment

Contract

Contract Operation

Contract operations include:

Contract Participant

An actor who participates in contract operations. Contract parties are classified into the following categories:

Contract Rights

Contract State

The set of up-to-date, private, and public information that manifests the condition of a contract at a certain point in history. In RGB, the contract state is constituted by:

Deterministic Bitcoin Commitment - DBC

Directed Acyclic Graph - DAG

Extra Transaction Proof - ETP

Genesis

Invoice

Global State

Lightning Network

A decentralized network of bidirectional payment (state) channels constituted by 2-of-2 mutisig wallet constructing and updating off-chain transactions. It represents a popular Bitcoin Layer 2 scaling solution.

Multi Protocol Commitment - MPC

Owned State

Ownership

Partially Signed Bitcoin Transaction - PSBT

A transaction which lacks some element of its signature and which can be completed/finalized with some additional elements later in time.

Schema

Seal Definition

Shard

Single-Use Seal

Stash

State Transition

Taproot

Transition Bundle

UTXO

Witness Transaction


The set of operations and rules contained in a contract which allows for the rightful update of the .

The operation which allows the verification of some data exchanged between parties according to some defined protocol rules. In RGB protocol these data are in form of ; the above data can be exchanged privately between the parties involved as, unlike Bitcoin protocol, they don't need to be registered on a public medium (e.g. the blockchain).

A defined mathematical object CCC, deterministically derived from applying a cryptographic operation to some structured input data mmm, called the message. The commitment can be registered in a defined publication medium (e.g. the blockchain) and embeds two operations:

Commit operation, which takes as inputs a public message mmm and a random value rrr, and by applying to them the chosen cryptographic algorithm returns a value C=commit(m,r)C = \text{commit}(m, r)C=commit(m,r).

Verify operation, which takes the value returned by the commit algorithm CCC, the public message mmm and the secret value rrr and returns True/False. verify(m,r,com)→(True/False)\text{verify}(m, r, com) \rightarrow (\text{True} / \text{False})verify(m,r,com)→(True/False).

Binding: requires that there cannot be two valid messages of the same commitment CCC. That is, it is computationally unfeasible to produce different m′ ∣ m′≠mm' \: | \: m' \neq mm′∣m′=m and r′ ∣ r′≠rr' \: | \: r' \neq rr′∣r′=r such that: verify(m,r,C)=verify(m′,r′,C)→True\text{verify}(m,r,C)=\text{verify}(m',r',C) \rightarrow \text{True}verify(m,r,C)=verify(m′,r′,C)→True

Hiding: requires that the message mmm cannot be easily discovered by commitment attempts, i.e., that rrr be uniformly sampled in a set RRR such that it is statistically independent of mmm.

The data transferred between parties that are subject to . In RGB there are 2 types of consignment:

Contract Consignment: provided by the contract issuer, includes the information about the contract setup, such as the and the .

Transfer Consignment: provided by the payer to the payee, contains all the state transition history from to the newly created unspent .

A set of established and executed digitally between certain parties through RGB protocol. A contract possesses an and , expressed in terms of ownership rights and executive rights. The contract state, rights and conditions of valid operations are defined using RGB . Only state and operations which allowed by the schema declarations and validation scripts are allowed to happen within the contract scope.

An update to the performed according to the rules defined in the contract .

Contract issuer: an actor creating contract .

Contract party: all actors who have some rights over RGB which have been provided through an .

RGB contract parties have different rights as a part of the contract conditions defined through RGB . The rights under RGB contracts can be classified into the following categories:

Ownership rights: the rights associated with the of some UTXO referenced by a .

Executive rights: the ability to construct the in a final form, i.e. to construct a valid satisfying validation rules.

The set of rules which allows for the registration of a provably single in a Bitcoin transaction. Specifically, RGB protocol embeds 2 forms of DBC:

A directed graph that does not contain any directed cycle thus allowing topological ordering. A Blockchain or an RGB Contract are examples of DAG.

The part of the that embeds the additional data necessary for the validation of commitment contained in a transaction, such as the internal PubKey and the Script Path Spend.

The set of data, regulated by a contract , which represents the starting state of every contract of RGB. It's the equivalent of Bitcoin Genesis Block at the client-side level.

A URL-encoded string embedding the necessary data in order to allow a payer counterpart to construct a .

The set of public properties included in the of a , defined in and optionally updatable according to the rule defined therein, which are not by any party.

The Merkle Tree structure used in RGB to include in a single Bitcoin Blockchain commitment the multiple of different contracts.

Part of the of a enclosed into an that contains the definition of the digital property being subjected to someone's .

The control and thus the possibility to spend a to which some client-side property isthat .

A declarative piece of code that contains the set of variables, rules, and according to which an RGB contract works.

The reference part of an which binds the commitment to a belonging to the new .

A branch of the chain of the RGB .

A promise to to a yet unknown message in the future, once and only once, such that commitment fact will be provably known to all members of a certain audience.

The set of client-side data related to one or more that undergo and are stored by the users.

The most important that makes possible the transition of an RGB State to a New State, changing data and/or ownership.

The Bitcoin's Segwit v1 transaction format detailed in and .

A set of RGB that belong to the same contract and that are committed in the same .

A Bitcoin Unspent Transaction Output. It is defined by a transaction hash and a vout index which, collectively, constitute an .

The transaction that provides the closing operation around a message that contains a an Tree.

commitment
witness transaction
MPC
DBC
ETP
Tapret
Link
contract
Seal Definition
Owned State
Link
Schema
contract state
consignment
client-side validation
Schema
Genesis
Genesis
Assignments
rights
active state
business logic
schema
contract state
schema
Genesis
State Transition
Genesis
ownership
contract state
Assignment
Schema
ownership
Seal Definition
contract state
state transition
schema
Global State
Owned State(s)
commitment
Opret
Tapret
Shard
Wikipedia link
Anchor
Tapret
taproot
schema
Link
base58
State Transition
state
contract
Genesis
owned
Link
Link
Transition Bundles
Link
state
contract
Assignment
ownership
Link
UTXO
assigned
Link
business logic
Link
Assignment
UTXO
owner
Link
DAG
State Transitions
commit
Link
contracts
validation
contract operation
state
Link
BIP341
BIP342
State Transitions
witness transaction
Link
outpoint
Seal
Multi Protocol Commitment
MPC