Last updated
Last updated
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.
In Bitcoin Blockchain, for instance, this process is meant to verify the correctness of the changes in the determined by the transactions collected into the sequence of ordered blocks. Thus, every block represents a state update.
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:
Privacy: details of each transaction are broadcasted and stored in public form (in particular: the amounts transacted and the receiving addresses, although pseudonyms).
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.
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.
Client-side Validation ensures that the following properties are met:
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.
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.
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 ).
Basically, what is relevant to the recipient is the which connects the history of the state transitions from the to the last state addressed to him (a of the whole data).
A compact reference of the validated state transition is committed in Layer 1 to be timestamped. This construction constitutes a and acts as an anti double-spending measure.
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 , no additional footprint in respect to an ordinary transaction.
Privacy: using a (such as ), the original data (the pre-image) that produced the commitment cannot be reconstructed and it is kept private by the parties.
The commitment structure used in Client-Side Validation (as in the RGB protocol, which we will cover in detail ) allows for important additional scalability features:
structures provide the deterministic link between the and the client-side data that represent the message to which the .
