Skip to content

Update text of Client-side Validation and Single-use Seals pages #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
zoedberg merged 2 commits into from
Aug 31, 2026
Merged

Update text of Client-side Validation and Single-use Seals pages #24

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
463257c
Update text of Client-side Validation and Single-use Seals pages
Aug 20, 2026
0d322f6
Apply suggestions from code review
MariJJhodl Aug 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 24 additions & 24 deletions distributed-computing-concepts/client-side-validation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,50 +1,50 @@
# 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.
In a distributed system, every validation process aims to **assess the validity and the chronological ordering of states**, hence to verify that state transitions correctly follow the protocol rules.

<figure><img src="../.gitbook/assets/state-passages.webp" alt=""><figcaption><p><strong>Consensus system allows for the tracking of the state evolution of some properties</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/state-passages.webp" alt=""><figcaption><p><strong>A consensus-based system allows the operator to track the changes of certain properties over time.</strong></p></figcaption></figure>

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**.
Taking the Bitcoin blockchain as an example, this tracking process is meant to verify that the changes to the [UTXO set](https://en.wikipedia.org/wiki/Unspent\_transaction\_output) are valid. In fact, with every new block added to the chain (i.e. the ordered sequence), the UTXO set gets modified. Thus, every block represents a **state update**.

<figure><img src="../.gitbook/assets/utxo-set-1.webp" alt=""><figcaption><p><strong>In Bitcoin the System State is represented by the UTXO Set, reflecting the ownership of bitcoins.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/utxo-set-1.webp" alt=""><figcaption><p><strong>In Bitcoin, the system state is represented by the UTXO Set, which represents the ownership of bitcoins.</strong></p></figcaption></figure>

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:
The main drawback of Layer 1's validation process is that **each node must validate all transactions (even those coming from other nodes) and store the related data** long after the block is added on top of the chain. 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).
* **Scalability**: the size limit of the blocks, versus the demand for blockspace per unit of time among 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**: the details of each transaction are broadcast and stored publicly (in particular, the amounts transacted and the receiving addresses are visible to everyone, albeit pseudonymous).

<figure><img src="../.gitbook/assets/blockchain-1.webp" alt=""><figcaption><p><strong>In Public Blockchains everyone needs to validate all the information leading to privacy and scalability issues.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/blockchain-1.webp" alt=""><figcaption><p><strong>In public blockchains, every node must validate and store every transaction, which generates scalability and privacy issues.</strong></p></figcaption></figure>

However, from the point of view of the recipient of a transaction, the only aspects that matter are:
However, from the recipient's perspective, only two aspects matter:

* 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.
* The most recent state transition, represented by a transaction addressed to the recipient themselves.
* The chronological sequence of transactions (and thus state transitions) leading up to the last one.

Basically, what is relevant to the recipient is the Directed Acyclic Graph which connects the history from a set of coinbase transactions to the state addressed to him (a subset of the whole data).
What is relevant to the recipient is the chain of ownership transfers from a set of coinbase transactions to the last transaction addressed to them, i.e. their Directed Acyclic Graph, which is only a subset of the complete dataset.

<figure><img src="../.gitbook/assets/transaction-graph-1.webp" alt=""><figcaption><p><strong>The transaction graph of Public Blockchains cannot be sharded due to internal consistency.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/transaction-graph-1.webp" alt=""><figcaption><p><strong>The transaction graph of public blockchains cannot be sharded: since any transaction may reference an output created anywhere in prior history, all nodes must maintain a consistent view of the entire history, in order to validate new blocks.</strong></p></figcaption></figure>

For this reason, the **logic of validation can be reversed** in the following terms:
For this reason, the **conventional validation logic can be reversed** as follows:

* 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**.
* Each party validates its **own portion of the history**, and thus the digital properties that matter to them.
* A compact reference to 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**.

<figure><img src="../.gitbook/assets/csv-blocks-1.webp" alt=""><figcaption><p><br><strong>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.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/csv-blocks-1.webp" alt=""><figcaption><p><br><strong>Layer 1 blocks remain public, while client-side validated state transitions are aggregated and committed through suitable Merkelization within Layer 1 transactions.</strong></p></figcaption></figure>

**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](../commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md), 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.
* **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 generated the commitment cannot be reconstructed, thus keeping it private to the parties involved.

<figure><img src="../.gitbook/assets/csv-shard-1.webp" alt=""><figcaption><p><strong>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.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/csv-shard-1.webp" alt=""><figcaption><p><strong>Multiple data packages can be aggregated in a single Layer 1 transaction. The Anchor structure establishes a deterministic link between the client-side data of the contract and the single-use seal.</strong></p></figcaption></figure>

The commitment structure used in Client-Side Validation (as in the RGB protocol, which we will cover in detail [later](../commitment-layer/commitment-schemes.md)) allows for important additional scalability features:
The commitment structure used in client-side validation (as implemented in the RGB protocol, which we will cover in detail [later](../commitment-layer/commitment-schemes.md)) 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.
* The aggregation of state transitions from different contracts (e.g., two different contracts related to 2 different digital assets committed in a single Bitcoin transaction).
* The bundling of multiple state transitions of the same asset in a single client-side operation.

[Anchor](../commitment-layer/anchors.md) structures provide the deterministic link between the [single-use seal](single-use-seals.md) and the client-side data that represent the message to which the [single-use seal is closed over](single-use-seals.md#seal-closing).
[Anchor](../commitment-layer/anchors.md) structures provide the deterministic link between the [single-use seal](single-use-seals.md) and the client-side data representing the message over which the [single-use seal is closed](single-use-seals.md#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**.
To guarantee the efficacy of the commitment scheme and the precise chronological ordering derived from Layer 1, a new cryptographic primitive needs to be introduced: the **Single-use Seal**.

***
Loading
Loading