# Features of RGB State

## Strict Type System

As described in the previous sections, the [state](https://docs.rgb.info/annexes/glossary#contract-state) represents a set of conditions that are subjected to validation against both the [business logic](https://docs.rgb.info/annexes/glossary#business-logic) and ordered history of commitments.

In RGB, this set of data is actually an **arbitrary rich set of data** which:

* Are **strongly typed**, meaning that **each variable has a clear type definition (e.g. u8) and lower and upper bounds.**
* Can be **nested**, meaning that a type can be constructed from other types.
* Can be organized in `lists`, `sets` or `maps`.

To properly encode data in the state in a reproducible way, a [Strict Type System](https://docs.rgb.info/annexes/rgb-library-map#strict-types-and-strict-encoding) has been adopted in RGB along with [Strict Encoding](https://docs.rgb.info/annexes/rgb-library-map#strict-types-and-strict-encoding). This means that:

* Encoding of the data is done following some [Schema](https://docs.rgb.info/annexes/glossary#schema) structure which, unlike JSON or YAML, defines a precise layout of the data, thus also allowing deterministic ordering of each data element.
* The ordering of elements within each collection (i.e., in lists, sets or maps) is also deterministic.
* Bounds (lower and upper) are defined for each variable or data structure. This property is also applied to the number of elements in each collection (the so called **Confinement**).
* All data fields are byte-aligned.
* Data serialization and hashing are performed deterministically (Strict Encoding), allowing **reproducible commitments** of the data to be created regardless of the system on which that operation is performed.
* Data creation according to the schema is **performed through a simple description language which compiles to binary form** from the Rust Language. Extension to other languages will be supported in the future.
* In addition, compilation according to the Strict Type System produces two types of output:
  * A **compile-time Memory Layout**.
  * **Semantic identifiers** associated with memory layout (i.e., the commitment to the name of each data field). For instance, this type of construction is able to make detectable the change of a single variable name, which **doesn't change the memory layout** but **changes the semantics**.
* Finally, Strict Type System allows for **versioning** of the compilation schema, thus enabling the tracking of consensus changes in contracts and the compilation engine. To this end each compilation of an RGB object, being it a Schema or RGB libraries themselves, produces an **unique fingerprint** such as:

`RWhwUfTMpuP2Zfx1~j4nswCANGeJrYOqDcKelaMV4zU#remote-digital-pegasus`

As a matter of fact, Strict Encoding is defined both at an extremely pure functional level (thus far away from object-oriented programming (OOP) philosophy) and at a very low level (almost a hardware definition, thus far removed from more abstract structures and languages).

### Size limitation of validated data

Regarding **data participating in state validation**, the RGB protocol consensus rule applies a **maximum size limit** of 2^16 bytes (64 KiB):

* To the size of **any type of data** participating in state validation (e.g. a maximum of 65536 x `u8`, 32768 x `u16`, etc...)
* To the **number of elements of each collection** employed in state validation. This is designed to:
  * Avoid unlimited growth of client-side validated data per each state transition.
  * Ensure that this size fits the register size of a particular virtual machine [AluVM](https://docs.rgb.info/rgb-state-and-operations/state-transitions) that is capable of performing complex validations along with RGB.

## The Validation != Ownership Paradigm in RGB

One of the most important features of RGB compared to most blockchain-based smart contract systems is based on the **clear separation between the validation task and ownership** that are defined by the protocol at the most fundamental level.

![](https://160813645-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaUAGORrT1fl6qzaZSTKt%2Fuploads%2Fgit-blob-c4cbae940236fe6ab5a24a9fb5c41d4fac5e6746%2Fvalidation-ownership-1.png?alt=media)

In practice:

* The **Validation** task, performed by users and observers of the protocol, ensures **how the properties of a smart contract can change** and thus the internal consistency and adherence of state transitions to the smart contract rule. This process is fully realized by the stratification of the stack of [RGB-specific](https://docs.rgb.info/annexes/rgb-library-map) libraries.
* The **Ownership** property, which, through the definition of the seal pointing to a Bitcoin UTXO, **defines who can change the state**. The security level of this property depends entirely on the security model of Bitcoin itself.

This type of separation **prevents the possibility of mixing the non-Turing complete capabilities of smart contracts with the public access to contract states** that is embedded in almost all blockchains with advanced programming capabilities. In contrast, **the use of these common "mixed" architectures has led to frequent and notable hacks** in which yet unknown vulnerabilities of smart contracts have been exploited by publicly accessing the contract state encoded in the blockchain.

Moreover, based on Bitcoin's transaction structure, RGB can exploit the **features of the Lightning Network** directly.

## RGB Consensus Changes

As another important feature, RGB has, in addition to Semantic Versioning of data, a **Consensus Update System**, which tracks changes in consent in [contracts](https://docs.rgb.info/annexes/glossary#contract) and [contract operations](https://docs.rgb.info/annexes/glossary#contract-operation).

There are basically two ways to update the consent rule embedded in the protocol.

### **Fast-forward**

A **fast-forward** update occurs when *some previously invalid rule becomes valid*. Despite the similarities, this kind of update is **NOT comparable to a blockchain hardfork**. The chronological history of this kind of changes is mapped into the contract through the [Ffv field](#components-of-a-contract-operation) of Contract Operation. Specifically, it is characterized by the following properties:

* Existing owners are not affected.
* New beneficiaries must upgrade their wallets.

### Push-back

A **push-back** update occurs when *some previously valid state becomes invalid*. Despite the similarities, this kind of update is **NOT comparable to a blockchain softfork**, and furthermore:

* Existing owners can lose assets if they update their wallets.
* It's actually a new protocol, no longer the same version of RGB.
* Can only occur through issuers reissuing assets on a new protocol and users using two wallets (for both the old and new protocols).