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 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).
• 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 which connects the history of the state transitions from the Genesis to the last state addressed to him (a 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 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, no additional footprint in respect to an ordinary transaction.
• Privacy: using a one-way cryptographic hash function (such as SHA-256), 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) 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 structures provide the deterministic link between the single-use seal and the client-side data that represent the message to which the single-use seal is closed over.

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.

---