I ricercatori di [[alloc] init] — Clara Shikhelman, Misha Komarov e Aleksei Moskvin — hanno rilasciato Shielded Bitcoin, un whitepaper che descrive un innovativo metaprotocollo di privacy costruito sul livello base di Bitcoin. Il design consente transazioni Bitcoin shielded senza richiedere operatori, soft fork o altre modifiche al consenso di Bitcoin. Sono disponibili il whitepaper e un annuncio sul blog, e il team ha condiviso la notizia su X.

Il protocollo definisce una struttura transazionale e un protocollo di indicizzazione per transazioni con forte tutela della privacy, basandosi su Bitcoin PIPEs per l'ancoraggio dei fondi dentro e fuori dal sistema. Il meccanismo PIPEs viene esaminato in dettaglio alla fine di questo articolo.

Questa proprietà di nessuna modifica al consenso è importante: il registro di Bitcoin registra importi e indirizzi in vista pubblica, e le modifiche alle sue regole hanno storicamente richiesto un ampio coordinamento a livello di rete. Un design che opera interamente all'interno dell'insieme di regole esistenti non dipende da quel processo per andare avantin

Un design simile a Bitcoin con dettagli molto diversi

L'architettura rispecchia deliberatamente quella di Bitcoin. Esiste un equivalente dell'UTXO, chiamato nota (note). Le transazioni consumano note come input, proprio come una normale transazione Bitcoin spende UTXO. Un witness dimostra che gli input consumati sono correttamente autorizzati, e i nodi — indexer, nel caso di un metaprotocollo — analizzano la cronologia delle transazioni e costruiscono uno stato corrente di quali monete sono spese e non spese.

Tutti i dettagli sottostanti, tuttavia, sono piuttosto diversi.

Transazioni che Bitcoin stesso ignora

Una transazione Shielded Bitcoin è semplicemente un blocco di dati con un prefisso — qualcosa come "shbtc:" — incorporato in una transazione Bitcoin tramite OP_RETURN, il campo witness o qualche altro metodo di trasporto dati. Questo è il pattern del metaprotocollo: le regole del protocollo sono applicate dai suoi stessi indexer anziché da Bitcoin, quindi la catena base non vede nulla oltre i dati ordinari. Il blocco di dati non ha significato per Bitcoin: la rete non fa nulla per verificarlo e non applica alcuna regola al riguardo.

Di conseguenza, è del tutto possibile che transazioni Shielded Bitcoin non valide finiscano on-chain. Spetta a uno Shielded Bitcoin Indexer, che osserva passivamente la blockchain, ignorare le transazioni che falliscono la validazione e rifiutarsi di applicarle quando aggiorna lo stato dei saldi della rete.

Nullifier invece di un set delle spese

Un indexer non elimina le note da un set di note non spese come Bitcoin rimuove gli UTXO spesi. Invece, mantiene un set di nullifier. Questo meccanismo consente a un utente di pubblicare pubblicamente una prova crittografata e un nullifier che dimostrano che una nota è stata spesa senza rivelare quale nota sia stata spesa. Piuttosto che verificare se una nota si trovi in un "set di note non spese", i partecipanti controllano se un dato nullifier sia già stato utilizzato.

Gli indexer costruiscono un merkle tree che cresce all'infinito e può solo essere esteso, contenente ogni nota mai creata, insieme al set di nullifier.

Per utilizzare il protocollo basta un nodo

Utilizzare il protocollo non rich altro che un nodo Bitcoin e uno Shielded Bitcoin indexer. Non è necessario alcun servizio, coordinatore o stato off-chain per recuperare i fondi. Funziona proprio come Bitcoin on-chain: all'utente servono solo il proprio nodo/indexer e le proprie chiavi.

Ogni wallet utente deriva una chiave segreta master, da cui viene creato ogni altro set di chiavi coinvolto — un design molto simile a un HD wallet in Bitcoin, dal quale è possibile generare molti set di indirizzi. sk_spend funge da chiave privata di spesa, sk_nf viene utilizzata per nullificare gli output delle note, vk_in decifra e visualizza le note in entrata, vk_out visualizza le transazioni in uscita, e sk_view genera un indirizzo di ricezione.

Quando un utente vuole fornire a qualcuno un indirizzo per ricevere fondi, genera un valore diversificatore d, simile a un valore di derivazione, e lo moltiplica contro la propria chiave sk_view. La chiave pubblica risultante pk_d, insieme a d, costituisce l'indirizzo dell'utente.

Il mittente genera quindi un valore casuale, l'r_seed, necessario sia per cifrare l'output della nota sia per la nullificazione. Gli output delle transazioni contengono solo tre elementi cifrati: il valore dell'output, il valore d che il destinatario ha fornito al mittente e il valore r_seed del mittente. Per cifrare, il mittente utilizza una coppia di chiavi effimere segrete e la chiave pubblica del destinatario per creare un segreto condiviso — entrambe le parti possono calcolare lo stesso segreto moltiplicando la propria chiave privata per la chiave pubblica dell'altra. L'output della nota viene cifrato con questo segreto condiviso, e la chiave effimera sk_eph è inclusa non cifrata così che il destinatario possa generare egli stesso il segreto condiviso.

I proof a conoscenza zero garantiscono la validità

Sul lato degli input, due cose sono necessarie affinché una transazione sia valida: un nullifier pubblico per ogni output di nota consumato e un proof a conoscenza zero che dimostri che (1) l'output della nota è incluso nel merkle tree delle note, (2) la transazione è autorizzata dalla chiave sk_spend appropriata, (3) il nullifier è correttamente derivato e (4) non si è verificata alcuna inflazione.

Il nullifier incorpora la chiave sk_nf, un valore ρ derivato dall'r_seed e la posizione della nota nel merkle tree degli output delle note. Sebbene nessuno possa sapere a quale output di nota corrisponda un nullifier, i proof a conoscenza zero in ogni transazione garantiscono che ogni nullifier aggiunto al set provenga da un output di nota valido. Gli indexer possono quindi semplicemente rifiutare i nullifier ripetuti anziché eliminare le note spese e, finché non ci sono ripetizioni, il sistema fornisce la stessa garanzia contro il double spending.

Il risultato netto è che le transazioni crittografate del metaprotocollo possono essere incorporate blockchain di Bitcoin, garantendo comunque che nulla venga speso due volte e che le monete non vengano inflazionate dal nulla.

Proprietà di privacy

Secondo l'analisi, il sistema è ben progettato in termini di proprietà di privacy ed è al livello di qualcosa come le shielded pool di Zcash. Il confronto delinea il panorama più ampio: Zcash offre transazioni shielded tramite regole integrate nel proprio protocollo, mentre questo design persegue proprietà comparabili sul livello base di Bitcoin senza toccare il consenso. Le considerazioni sulla privacy che sorgono al momento dell'ingresso e dell'uscita dal metaprotocollo saranno dettagliate in un prossimo paper, lasciando i punti di ingresso e uscita del sistema tra i dettagli da seguire man mano che il lavoro avanza. A differenza dei coinjoin, non vi è alcuna preoccupazione riguardo alla misurazione della privacy o alla necessità di remix periodici.

Ancoraggio dei fondi con PIPEs v2

Il peg previsto si basa su PIPEs v2, uno schema di witness encryption. PIPEs consentono di cifrare una chiave privata con un programma o meccanismo che non rivelerà la chiave a meno che non venga fornito un ZK-proof che dimostri il soddisfacimento di una determinata condizione — ad esempio, lo stato di un certo UTXO, o che una transazione sia stata confermata. Ciò consentirebbe a un peg di funzionare senza un operatore, una federazione o qualsiasi terza parte che custodisca i fondi — una proprietà notevole, dato che i design di peg che estendono Bitcoin hanno tipicamente fatto affidamento su tali custodi. Non richiede soft fork o modifiche al protocollo di Bitcoin e avviene interamente off-chain.

La fase successiva del lavoro del team è un meccanismo di peg che consentirebbe agli utenti di depositare fondi in Shielded Bitcoin utilizzando chiavi controllate crittograficamente tramite PIPEs, che verrebbero poi "sbloccate" generando uno ZK-proof di legittime transazioni di peg out confermate on-chain. I lavori sul paper che definisce questo aspetto del sistema sono attualmente in corso e dovrebbero essere pubblicati nel prossimo futuro; insieme al paper sulla privacy in entrata/uscita, completeranno i punti lasciati aperti dal whitepaper.

---

Questo articolo, scritto da Shinobi, è apparso per la prima volta su Bitcoin Magazine.