# Client-side Validation The goal of every validation process in a distributed system is the **ability to assess the validity and chronological ordering of states**, hence to verify the correctness of the protocol rules of the state transitions that have occurred.

Consensus system allows for the tracking of the state evolution of some properties

In Bitcoin Blockchain, for instance, this process is meant to verify the correctness of the changes in the [UTXO set](https://en.wikipedia.org/wiki/Unspent_transaction_output) determined by the transactions collected into the sequence of ordered blocks. Thus, every block represents a **state update**.

In Bitcoin the System State is represented by the UTXO Set, reflecting the ownership of bitcoins.

The main drawback of Layer 1's validation process is that **each node has to validate each transaction from everybody and store the related data** once block inclusion takes place. This architecture leads to two main issues: * **Scalability**: the size limit of the blocks vs. the demand of blockspace per unit time shared by all willing participants limits the transaction throughput (i.e. a maximum of 1 MB on \~10 minutes on average on bitcoin, taking into account [witness discount](https://en.bitcoin.it/wiki/Segregated_Witness)). * **Privacy**: details of each transaction are broadcasted and stored in public form (in particular: the amounts transacted and the receiving addresses, although pseudonyms).

In Public Blockchains everyone needs to validate all the information leading to privacy and scalability issues.

However, from the point of view of the recipient of a transaction, the only aspects that matter are: * The last state transition, that is represented by a transaction addressed to him. * The chronological sequence of transactions (and thus state transitions) leading up to the last state transition. Basically, what is relevant to the recipient is the [Directed Acyclic Graph](https://docs.rgb.info/annexes/glossary#directed-acyclic-graph-dag) which connects the history of the state transitions from the [Genesis](https://docs.rgb.info/annexes/glossary#genesis) to the last state addressed to him (a [Shard](https://docs.rgb.info/annexes/glossary#shard) of the whole data).

The transaction graph of Public Blockchains cannot be sharded due to internal consistency.

For this reason, the **logic of validation can be reversed** in the following terms: * Each part validates its **own part of the history** and thus the digital properties that matter to him. * A compact reference of the **validated state transition is committed in Layer 1** to be timestamped. This construction constitutes a [Proof-of-Publication](https://petertodd.org/2017/scalable-single-use-seal-asset-transfer) and acts as an **anti double-spending measure**.


Layer 1's blocks are kept public, but client-side validated state transitions are aggregated and committed through suitable merkelization in Layer 1's transactions.

**Client-side Validation** ensures that the following properties are met: * **Scalability**: since the commitment of the verified state, which must be stored by all, has, at least, a small footprint (order of tens of bytes), or, in [some commitment scheme](https://docs.rgb.info/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret), no additional footprint in respect to an ordinary transaction. * **Privacy**: using a [one-way cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) (such as [SHA-256](https://en.wikipedia.org/wiki/SHA-2)), the original data (the pre-image) that produced the commitment cannot be reconstructed and it is kept private by the parties.

Several shards can be aggregated in a single Layer 1 transaction. The Anchor structure establish a link between the client-side data of the contract and the single-use seal.

The commitment structure used in Client-Side Validation (as in the RGB protocol, which we will cover in detail [later](https://docs.rgb.info/commitment-layer/commitment-schemes)) allows for important additional scalability features: * Aggregate state transitions of different contracts (e.g., two different contracts related to 2 different digital assets committed in a single Bitcoin transaction). * Bundle more than one state transition of the same asset in the same client-side operation. [Anchor](https://docs.rgb.info/commitment-layer/anchors) structures provide the deterministic link between the [single-use seal](https://docs.rgb.info/distributed-computing-concepts/single-use-seals) and the client-side data that represent the message to which the [single-use seal is closed over](https://docs.rgb.info/single-use-seals#seal-closing). To guarantee the efficacy of the commitment scheme and precise chronological ordering derived from Layer 1, the use of a new cryptographic primitive needs to be introduced: the **Single-use Seal**. *** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rgb.info/distributed-computing-concepts/client-side-validation.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.