Pagamenti privati su Bitcoin niente di leggibile on-chain
zkCoins porta vera privacy a Bitcoin. Importi, mittente, destinatario e cronologia restano off-chain — provati con zero-knowledge, mentre ogni trasferimento pubblica su Bitcoin solo un nullifier da ~64 byte.
~140 vByte · interamente pubblico · uno per pagamento
un ordine di grandezza più piccolo
Trasferimento zkCoins
un nullifier da ~64 byte
~16 vByte on-chain · dati dei coin off-chain
I dati dei coin non toccano mai la chain. Ogni trasferimento pubblica su Bitcoin un nullifier da ~64 byte — circa 16 vByte, contro ~140 di un trasferimento classico — costante indipendentemente da quanti coin muove.
"Use the chain for what the chain is good for — an immutable ordering of commitments to prevent double-spending."
— Robin Linus, co-autore di Shielded CSV
Whitepaper · ePrint 2025/068
Shielded CSV: Private and Efficient Client-Side Validation
Una variante di Client-Side Validation che preserva la privacy, regolata direttamente su Bitcoin.
Autori
Jonas Nick (Blockstream) · Liam Eagen (Alpen Labs) · Robin Linus (ZeroSync)
Pubblicato
gennaio 2025 (ePrint) · settembre 2024 (whitepaper)
Client-Side Validation disaccoppia la validazione delle transazioni dal consensus Bitcoin spostandola al destinatario. Shielded CSV migliora i design CSV precedenti nascondendo del tutto la cronologia delle transazioni: ogni trasferimento lascia trapelare solo un nullifier di 64 byte sulla chain, il resto è verificato client-side tramite succinct zero-knowledge proof. Il protocollo è compatibile con Bitcoin as-is — nessun soft fork, nessun hard fork — e punta a circa un ordine di grandezza in più di transazioni al secondo rispetto alla sola base layer.
zkCoins v1 implementa fedelmente il modello del paper: ogni trasferimento pubblica il proprio nullifier da ~64 byte direttamente su Bitcoin come firma semi-aggregata, così che la chain stessa garantisca ogni nullifier di cui un verifier ha bisogno per i suoi controlli double-spend — nessun dato di batch off-chain, nessuna assunzione di data-availability. Circa 16 vByte on-chain per trasferimento, nell'ordine di ~100 transazioni al secondo.
Trasferimenti privati, un minuscolo nullifier su Bitcoin
I dati dei coin restano off-chain. Ogni trasferimento pubblica su Bitcoin solo un nullifier da ~64 byte, provato con zero-knowledge — così privacy e piccola impronta on-chain vincono insieme.
Impronta on-chain
Un nullifier per trasferimento
I dati dei coin non toccano mai la chain. Ogni trasferimento pubblica su Bitcoin un nullifier da ~64 byte — niente di leggibile su importi o parti.
Grafo delle transazioni
Niente di collegabile
A differenza di RGB o Taproot Assets, la cronologia resta nascosta sotto una zero-knowledge proof. I destinatari verificano la validità senza mai vedere la discendenza.
Compatibilità
Bitcoin, invariato
Nessun soft fork, nessun hard fork. I protocolli CSV usano la chain solo per l'ordinamento e la prevenzione dei double-spend.
Costo
Una frazione di un trasferimento Bitcoin
Ogni trasferimento costa circa 16 vByte on-chain — una frazione di un trasferimento Bitcoin da ~140 vByte, all'incirca un ordine di grandezza più piccolo — costante indipendentemente da quanti coin muove.
Come funziona
La chain ordina, il destinatario valida
Le blockchain tradizionali chiedono a ogni nodo di validare ogni transazione. Shielded CSV inverte questo — la validazione passa al destinatario, e Bitcoin fa solo ciò per cui è unico.
1
Il mittente prova
Il mittente crea un trasferimento e genera una succinct validity proof dell'intera cronologia del coin — dimensione costante, qualunque sia l'età del coin.
2
La proof va al destinatario
La proof viaggia direttamente al destinatario, off-chain. Solo mittente e destinatario vedono importi, parti e cronologia — nessun importo o parte viene scritto sulla chain.
3
Il nullifier viene pubblicato su Bitcoin
Il nullifier da ~64 byte del trasferimento viene pubblicato su Bitcoin come firma semi-aggregata. La pubblicazione è permissionless — qualsiasi wallet può auto-pubblicare — e la chain stessa conserva ogni nullifier di cui un verifier ha bisogno.
4
Il destinatario verifica client-side
Il destinatario ri-verifica localmente la zero-knowledge proof completa del coin — un singolo controllo in tempo costante, qualunque sia la lunghezza della cronologia — e la accetta senza fidarsi di terze parti.
5
Bitcoin previene i double-spend
Bitcoin registra ogni nullifier in ordine canonico, e la prima occorrenza on-chain della state key di un coin seleziona la sua unica transizione valida. L'unico compito della chain: garantire che ogni coin sia speso esattamente una volta — senza bisogno di alcun dato off-chain.
In numeri
Bitcoin, accanto a Shielded CSV
Metrica
Bitcoin (classico)
zkCoins v1
Dati on-chain
transazione completa (~140 vByte)
nullifier da ~64 byte per trasferimento
Costo per trasferimento
~140 vByte
~16 vByte per trasferimento
Privacy
Nessuna — interamente pubblico
Piena — niente di leggibile on-chain
Verifica
Script completo per tx
1× proof di trasferimento
Dimensione proof
N/A
Costante, indipendente dalla cronologia
Confini
Cosa Shielded CSV non è
Qui la privacy è strutturale, non un add-on. Vale la pena essere precisi su ciò che questo protocollo deliberatamente non è.
Non una sidechain
Usa Bitcoin L1 direttamente — nessun consensus separato, nessun bridge verso una chain straniera.
Non un rollup
Nessun sequencer, nessun layer di data-availability — i nullifier vivono su Bitcoin stesso. Le validity proof si muovono peer-to-peer tra mittente e destinatario; il nullifier da ~64 byte di ogni trasferimento viene ancorato a Bitcoin L1.
Non un mixer
La privacy è strutturale, non offuscamento — un set di anonimato globale di ogni coin, non un piccolo pool per round.
Non un token
Nessun token di protocollo nativo da bootstrapare. Il valore vive in coin validati client-side.
Non un soft fork
Funziona su Bitcoin come esiste oggi — nessun cambio di consensus, nessun nuovo opcode.
Roadmap
Il percorso verso il mainnet
AttivoProssimoPianificatoOrizzonte
Phase 01
Fondamenta
Q2 2026Attivo
Lo stack di proving e il confine wallet–server. Tutto ciò che segue dipende da questo.
Migrazione del circuit zero-knowledge.Portare il circuit di state-transition su un sistema di proving nativo per la ricorsione con un hash SNARK-friendly.
Proving lato server su hardware commodity.Target Apple Silicon single-host — nessuna farm GPU, nessun servizio di proving cloud. Il wallet detiene solo la private key.
Confine wallet via BIP-340 Schnorr.Il wallet firma un digest SHA-256 dello state calcolato dal server. Nessuno zero-knowledge nel browser.
Roundtrip end-to-end su signet.Creare account, mintare, inviare, ricevere — il loop utente completo gira su un testnet Bitcoin pubblico.
Phase 02
Indurimento pre-mainnet
Q3 2026Prossimo
Chiudere i gap di protocollo tra «funziona su signet» e «sicuro con Bitcoin reale».
Nascondere i commitment dei destinatari.Eliminare il legame residuo tra mittente, destinatario e identificatore del coin.
Accumulo di nullifier sicuro alle reorg.Degradare con grazia quando la chain canonica si riorganizza, invece di bloccarsi.
Proof di freschezza per coin.I destinatari verificano l'età di un coin localmente senza fidarsi di terze parti.
Suite di test di sicurezza derivata dal paper.L'insieme completo delle proprietà formali del paper Shielded CSV, codificate come test failing-witness.
Phase 03
Bridge BTC trustless
Q4 2026Pianificato
Mint e burn contro BTC nativo senza fidarsi dell'issuer. Il più grande gap di fiducia lato utente si chiude qui.
Bridge in stile BitVM2 / Clementine.Modello di fiducia 1-of-N honesty. La stessa costruzione in esecuzione sul mainnet Citrea.
Light client Bitcoin ricorsivo.Una succinct proof che un deposito è atterrato a profondità ≥ 6 nella chain canonica.
Ricorsione → wrapping Groth16.Portare le nostre proof adatte alla ricorsione in un verifier che Bitcoin script può controllare.
Scaling della federation: N=3 → N=100.Partire con una federation mono-operatore; crescere fino a cento membri indipendenti, dove basta una key deletion onesta.
Run di integrazione su signet.Roundtrip completo peg-in / peg-out incluso uno scenario di operatore deliberatamente malevolo.
Phase 04
Atomic swap Lightning
Q1 2027Pianificato
Muovere valore tra Lightning e zkCoins in modo atomico — nessuna fiducia al provider, nessun bridge custodial.
HTLC sulla transaction di funding del nullifier.L'atomicità vive su Bitcoin layer 1, non sul layer dei coin privati. Primitive standard, nessun soft fork.
Flussi LN ↔ zkCoins simmetrici.Comprare con sats Lightning e rivendere in sats Lightning, entrambe le direzioni trustless.
Liquidità anticipata dai provider.Chiunque può gestire uno swap provider; il protocollo impone l'onestà, non l'operatore.
Pattern di swap che preserva la privacy.Uno swap provider apprende il lato LN, mai il grafo interno zkCoins.
Phase 05
Posizionamento di lungo termine
2027 +Orizzonte
Sostituire le tecnologie di bridge di oggi con quelle di domani — senza cambiare il protocollo.
Sistema di proving di nuova generazione.Portare su un field più piccolo con un hash più veloce una volta stabilizzato lo stack upstream. La struttura algoritmica resta.
Upgrade della costruzione del bridge.I successori drop-in di BitVM2 (Glock, Mosaic) riducono il costo di dispute on-chain di due ordini di grandezza. Il contract del circuit è invariato.
Diversità della federation.Reclutare organizzazioni indipendenti come membri della federation finché one-honest-deletion non è un'assunzione significativa.
Trusted setup del verifier del bridge.Una ceremony con 30–60 contributor sostituisce il set di parametri Groth16 mono-contributor usato per testare il verifier del bridge — le proof proprie di zkCoins sono trasparenti (FRI) e non richiedono setup.
Nota. Le date indicano finestre target per il lavoro di engineering, non una data mainnet garantita. zkCoins gira in un ambiente di test pubblico finché non termina l'indurimento pre-mainnet; nessun Bitcoin reale è a rischio prima.
zkCoins porta Shielded CSV in un wallet self-custodial — Bitcoin privato su L1, nessun soft fork. Teniamo una linea aperta per venture fund, family office e angel strategici che valutano il progetto.
Il protocollo si basa su ricerca pubblicata (ePrint 2025/068), lo stack è open source e la roadmap è pubblica. Non stiamo raccogliendo attivamente — ma siamo aperti a conversazioni prima del mainnet.
zkCoins è un wallet self-custodial per Shielded CSV, un protocollo di privacy per Bitcoin. Importi, mittente, destinatario e cronologia delle transazioni restano off-chain, provati con zero-knowledge e verificati client-side. Ogni trasferimento pubblica su Bitcoin solo un nullifier da ~64 byte.
zkCoins è un nuovo token o altcoin?
No — zkCoins non è una blockchain separata, un altcoin, né un token di protocollo nativo. È un layer di client-side-validation ancorato a Bitcoin L1; il valore vive in coin validati client-side. Spostare BTC on-chain dentro e fuori usa un bridge, che è in roadmap.
zkCoins richiede un soft fork?
No. Shielded CSV funziona su Bitcoin come esiste oggi — nessun soft fork, nessun hard fork, nessun nuovo opcode. La chain è usata solo per ordinare commitment e prevenire double-spend.
Come mantiene private le transazioni zkCoins?
Ogni spend è provato con una zero-knowledge proof e condiviso off-chain. I dati dei coin — importi, parti e cronologia — non toccano mai Bitcoin; sulla chain viene pubblicato solo un nullifier da ~64 byte per trasferimento.
zkCoins è self-custodial?
Sì. Le chiavi sono generate e memorizzate localmente nel browser e non lasciano mai il tuo dispositivo. zkCoins è peer-to-peer, senza coordinator o custodian che possa congelare fondi o spegnere la rete.
Cos'è Shielded CSV?
Shielded CSV (Client-Side Validation) è un protocollo Bitcoin che preserva la privacy dal paper di Jonas Nick, Liam Eagen e Robin Linus (ePrint 2025/068). zkCoins v1 lo implementa fedelmente: ogni trasferimento pubblica su Bitcoin un nullifier da ~64 byte, tutto il resto è verificato client-side.
Il ruolo del publisher è davvero decentralizzato?
La pubblicazione è permissionless, e qualsiasi wallet può auto-pubblicare i propri trasferimenti su Bitcoin a costo banale — questo limita quanto può chiedere un publisher dominante. L'economia competitiva favorisce l'operatore più veloce e meglio capitalizzato, quindi una certa concentrazione è attesa. È solo un rischio di liveness: un publisher non detiene mai la custody e al massimo può censurare o ritardare un trasferimento, mai rubare o forgiare coin. Analisi completa sulla pagina Risks delle docs.
Dove vivono i nullifier?
Su Bitcoin. Ogni trasferimento pubblica il proprio nullifier da ~64 byte direttamente sulla chain come firma semi-aggregata, così che Bitcoin stesso garantisca la disponibilità di ogni nullifier di cui un verifier ha bisogno per controllare i double-spend — nessun dato di batch off-chain e nessun layer di data-availability separato di cui fidarsi. I dati dei coin — importi, parti e cronologia — restano comunque off-chain, provati con zero-knowledge, e non sono mai necessari per ricostruire la vista pubblica dei double-spend.
Prova Bitcoin privato oggi
Il wallet zkCoins gira nel browser. Le chiavi sono generate e memorizzate localmente — non lasciano mai il tuo dispositivo. Attualmente su una rete di test pubblica; nessun Bitcoin reale è a rischio.