# Glossary

### Anchor

Set of client-side data that proves the inclusion of a unique [commitment](#commitment) inside a transaction. In RGB protocol it is constituted by:

* The Bitcoin transaction ID of the [witness transaction](#witness-transaction).
* The Multi Protocol Commitment - [MPC](#multi-protocol-commitment-mpc).
* The Deterministic Bitcoin Commitment - [DBC](#deterministic-bitcoin-commitment-dbc).
* The [ETP](#extra-transaction-proof-etp) in the case of [Tapret](https://docs.rgb.info/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret) 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.

[Link](https://docs.rgb.info/rgb-library-map#aluvm).

### Assignment

The RGB-equivalent of a transaction output modifying, updating or creating some properties of the state of a [contract](#contract). It is formed by:

* A [Seal Definition](#seal-definition)
* An [Owned State](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#owned-states)

[Link](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#assignments-of-an-owned-state)

### Business Logic

The set of operations and rules contained in a contract [Schema](#schema) which allows for the rightful update of the [contract state](#contract-state).

### Client-side Validation

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 [consignment](#consignment); 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).

### Commitment

A defined mathematical object $$C$$, deterministically derived from applying a cryptographic operation to some structured input data $$m$$, 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 $$m$$ and a random value $$r$$, and by applying to them the chosen cryptographic algorithm returns a value $$C = \text{commit}(m, r)$$.
* ***Verify** operation, which* takes the value returned by the commit algorithm $$C$$, the public message $$m$$ and the secret value $$r$$ and returns True/False. $$\text{verify}(m, r, com) \rightarrow (\text{True} / \text{False})$$.

The commitment is required to possess two fundamental security properties:

* ***Binding***: requires that there cannot be two valid messages of the same commitment $$C$$. That is, it is computationally unfeasible to produce different $$m' : | : m' \neq m$$ and $$r' : | : r' \neq r$$ such that: $$\text{verify}(m,r,C)=\text{verify}(m',r',C) \rightarrow \text{True}$$
* ***Hiding***: requires that the message $$m$$ cannot be easily discovered by commitment attempts, i.e., that $$r$$ be uniformly sampled in a set $$R$$ such that it is statistically independent of $$m$$.

### Consignment

The data transferred between parties that are subject to [client-side validation](#client-side-validation). 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 [Schema](#schema) and the [Genesis](#genesis).
* **Transfer Consignment**: provided by the payer to the payee, contains all the state transition history from [Genesis](#genesis) to the newly created unspent [Assignments](#assignment).

### Contract

A set of [rights](#contract-rights) established and executed digitally between certain parties through RGB protocol. A contract possesses an [active state](https://docs.rgb.info/rgb-state-and-operations/state-transitions#state-generation-and-active-state) and [business logic](#business-logic), expressed in terms of ownership rights and executive rights. The contract state, rights and conditions of valid operations are defined using RGB [schema](#schema). Only state and operations which allowed by the schema declarations and validation scripts are allowed to happen within the contract scope.

### Contract Operation

An update to the [contract state](#contract-state) performed according to the rules defined in the contract [schema](#schema).

Contract operations include:

* [Genesis](#genesis)
* [State Transition](#state-transition)

### Contract Participant

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

* **Contract issuer**: an actor creating contract [Genesis](#genesis).
* **Contract party**: all actors who have some [ownership](#ownership) rights over RGB [contract state](#contract-state) which have been provided through an [Assignment](#assignment).

### Contract Rights

RGB contract parties have different rights as a part of the contract conditions defined through RGB [Schema](#schema). The rights under RGB contracts can be classified into the following categories:

* Ownership rights: the rights associated with the [ownership](#ownership) of some UTXO referenced by a [Seal Definition](#seal-definition).
* Executive rights: the ability to construct the [contract state](#contract-state) in a final form, i.e. to construct a valid [state transition](#state-transition) satisfying [schema](#schema) validation rules.

### 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:

* [Global State](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#global-state)
* [Owned State(s)](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#owned-states)

### Deterministic Bitcoin Commitment - DBC

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

* [Opret](https://docs.rgb.info/commitment-layer/deterministic-bitcoin-commitments-dbc/opret)
* [Tapret](https://docs.rgb.info/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret)

### Directed Acyclic Graph - DAG

A directed graph that does not contain any directed cycle thus allowing topological ordering. A Blockchain or an RGB Contract [Shard](#shard) are examples of DAG.

[Wikipedia link](https://en.wikipedia.org/wiki/Directed_acyclic_graph)

### Extra Transaction Proof - ETP

The part of the [Anchor](https://docs.rgb.info/commitment-layer/anchors) that embeds the additional data necessary for the validation of [Tapret](https://docs.rgb.info/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret) commitment contained in a [taproot](#taproot) transaction, such as the internal PubKey and the Script Path Spend.

### Genesis

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

[Link](https://docs.rgb.info/rgb-state-and-operations/state-transitions#genesis)

### Invoice

A [base58](https://en.wikipedia.org/wiki/Binary-to-text_encoding#Base58) URL-encoded string embedding the necessary data in order to allow a payer counterpart to construct a [State Transition](#state-transition).

### Global State

The set of public properties included in the [state](#contract-state) of a [contract](#contract), defined in [Genesis](#genesis) and optionally updatable according to the rule defined therein, which are not [owned](#ownership) by any party.

[Link](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#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.

[Link](https://lightning.network/)

### Multi Protocol Commitment - MPC

The Merkle Tree structure used in RGB to include in a single Bitcoin Blockchain commitment the multiple [Transition Bundles](#transition-bundle) of different contracts.

[Link](https://github.com/rgb-protocol/RGB-Documentation/blob/master/annexes/commitment-layer/multi-protocol-commitments-mpc.md)

### Owned State

Part of the [state](#contract-state) of a [contract](#contract) enclosed into an [Assignment](#assignment) that contains the definition of the digital property being subjected to someone's [ownership](#ownership).

[Link](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#owned-states)

### Ownership

The control and thus the possibility to spend a [UTXO](#utxo) to which some client-side property isthat [assigned](#assignment).

### 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.

[Link](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)

### Schema

A declarative piece of code that contains the set of variables, rules, and [business logic](#business-logic) according to which an RGB contract works.

[Link](https://docs.rgb.info/rgb-contract-implementation/schema)

### Seal Definition

The reference part of an [Assignment](#assignment) which binds the commitment to a [UTXO](#utxo) belonging to the new [owner](#ownership).

[Link](https://docs.rgb.info/rgb-state-and-operations/components-of-a-contract-operation#seal-definition)

### Shard

A branch of the [DAG](#directed-acyclic-graph---dag) chain of the RGB [State Transitions](#state-transition).

### Single-Use Seal

A promise to [commit](#commitment) 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.

[Link](https://docs.rgb.info/distributed-computing-concepts/single-use-seals)

### Stash

The set of client-side data related to one or more [contracts](#contract) that undergo [validation](#client-side-validation) and are stored by the users.

### State Transition

The most important [contract operation](#contract-operation) that makes possible the transition of an RGB State to a New State, changing [state](#contract-state) data and/or ownership.

[Link](https://docs.rgb.info/rgb-state-and-operations/state-transitions#state-transitions-and-their-mechanics)

### Strict Type System

An infrastructure that allows to create complex types which are deterministically identified by their `semId`. It is used by schemas to precisely define the data type for their state.

[Link](https://docs.rgb.info/rgb-library-map#strict-types).

### Taproot

The Bitcoin's Segwit v1 transaction format detailed in [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki).

### Transition Bundle

A set of RGB [State Transitions](#state-transition) that belong to the same contract and that are committed in the same [witness transaction](#witness-transaction).

[Link](https://docs.rgb.info/rgb-state-and-operations/state-transitions#transition-bundle)

### UTXO

A Bitcoin Unspent Transaction Output. It is defined by a transaction hash and a *vout* index which, collectively, constitute an [outpoint](https://en.bitcoin.it/wiki/Protocol_documentation#tx).

### Witness Transaction

The transaction that provides the [Seal](#single-use-seal) closing operation around a message that contains a [Multi Protocol Commitment](#multi-protocol-commitment-mpc) an [MPC](#multi-protocol-commitment-mpc) Tree.

***