Il termine CSV come sigla di client-side validation, in italiano Validazione Lato Client, (da non confondere con CSV Check Sequence Verify del BIP 112) si riferisce ad una modalità di gestione della verifica delle side-chain.

La maggior parte delle blockchain pubbliche esistenti operano con un modello di consenso globale, in cui tutti i nodi validano tutte le transazioni, condividono le informazioni sulle transazioni tra loro e mantengono uno stato globale unificato.

Tuttavia, questo modello presenta una serie di sfide, tra cui:

• Limitazioni di scalabilità che rendono costoso convalidare tutte le interazioni contrattuali;
• Costi elevati che portano a un'operazione centralizzata dei nodi;
• Mancanza di privacy a causa delle informazioni di transazione aperte.

La Validazione Lato Client (CSV) propone un approccio alternativo: richiede solo al livello di consenso di adempiere agli impegni crittografici associati agli eventi del ledger, mentre memorizza le informazioni effettive sugli eventi (il ledger) fuori dalla blockchain.

Questo approccio, che origina dal lavoro di Peter Todd, è definito "Validazione Lato Client". CSV sposta i dati di transazione fuori dalla blockchain, dove vengono archiviati e verificati i dettagli, e solo le informazioni minime vengono inviate sulla blockchain. Inoltre, i dati di transazione vengono trasferiti fuori dalla blockchain solo tra il mittente e il destinatario. Ad esempio, in una transazione del mondo reale, la convalida è richiesta solo quando il wallet e le parti richiedono l'accesso ai dati del contratto.

Caratteristiche chiave di CSV:

• Le informazioni dettagliate sulle transazioni vengono archiviate fuori dalla blockchain e validate solo sul client;
• Solo gli impegni ai dati di transazione vengono archiviati sulla catena;
• La convalida si applica solo alle transazioni di cui gli utenti devono essere a conoscenza.

La CSV può sfruttare le regole di consenso, come ad esempio permettere che un output venga speso una sola volta all'interno di una block chain valida, ma può anche imporre regole aggiuntive conosciute solo da coloro interessati alla convalida.

Un protocollo di CSV concettualmente semplice potrebbe associare un token a un particolare UTXO. Solo l'insieme dei validatori deve essere a conoscenza di tale associazione; non è necessario pubblicarla sulla block chain o in qualsiasi altro luogo pubblico. Quando l'UTXO viene speso, la transazione di spesa associa il token a un nuovo UTXO.
Se Alice attualmente controlla l'UTXO associato al token e Bob desidera acquistarlo da lei, può fornirgli una prova dell'associazione originale, e poi lui può utilizzare la sua copia convalidata della block chain più la CSV per verificare la storia di ogni trasferimento del token fino ad Alice. Può anche verificare che una transazione creata da Alice sia correttamente formattata per assegnare il token a un UTXO che Bob controlla.

Esempi di protocolli CSV sono:

• RGB
• Taproot Assets, precedentemente chiamato Taro

Entrambi i protocolli sono progettati per essere compatibili con transazioni off-chain, come i pagamenti tramite Lightning Network. Similmente al ciclo di vita di un canale Lightning, viene pubblicata una transazione di setup on-chain che vincola i token al controllo condiviso delle parti coinvolte; una serie di transazioni off-chain ciascuna vincola l'allocazione attuale dei token tra le parti; e una transazione contenente l'impegno finale viene pubblicata on-chain.

Solo i wallet che desiderano supportare gli RGB o gli Asset Taproot devono comprendere il protocollo, e solo un wallet che vuole inviare o ricevere un token specifico o un altro contratto di convalida lato client deve sapere qualcosa su tale contratto. Per tutti gli altri, le transazioni create con RGB e Asset Taproot sembrano transazioni Bitcoin regolari.