Una nuova second layer solution: Taproot!

Taproot è un potenziale aggiornamento al protocollo Bitcoin proposto per la prima volta dal collaboratore di “Bitcoin Core” Gregory Maxwell, e si trova nelle sue ultime fasi di sviluppo. La tecnologia consiste in una combinazione intelligente di trucchi crittografici che consentirebbero agli utenti di nascondere complessi smart contracts all’interno di transazioni dall’aspetto normale: la complessità viene rivelata solo se le parti di un contratto non collaborano.

Facendo leva su questo tipo di idea, i programmatori di Bitcoin hanno speculato su un nuovo concetto denominato pool di pagamento. Queste pool consentirebbero a determinati gruppi di utenti di condividere la proprietà di monete digitali (tecnicamente: UTXO) registrate sulla blockchain di Bitcoin, consentendo ai singoli membri del gruppo di effettuare (o ricevere) pagamenti. Questo meccanismo rende le pool di pagamento una nuova soluzione “Layer Two”.

Come funziona una pool di pagamento?

Ci sono diverse proposte relative a diverse tipologie di “pool di pagamento”, ed esse variano solo leggermente l’una dall’altra, infatti il concetto di base è sempre lo stesso. Scopriamolo.

Innanzitutto, per creare una pool di pagamento, gli utenti combinano le loro (frazioni di) Bitcoin aggregandole in un indirizzo Taproot condiviso tra loro. Quindi, diciamo che Alice possiede tre monete, Bob possiede due monete e Carol possiede una moneta, per un totale di sei. Insieme, creano una transazione che invia queste monete all’indirizzo condiviso Taproot, rendendolo una pool di pagamento con disponibili sei monete.

Sulla blockchain, l’indirizzo della pool di pagamento sembra un normale indirizzo Bitcoin, che ora contiene sei monete. In realtà, Alice, Bob e Carol usando abilmente Taproot si sono assicurati che ognuno di loro mantenga il controllo della propria quota di monete all’interno della pool. Alice può in qualsiasi momento riprendersi tre monete dall’indirizzo, Bob può in qualsiasi momento rivendicarne due e Carol una.

Esistono solo due opzioni principali per spendere monete dall’indirizzo Taproot.

La prima opzione è spenderle direttamente dall’indirizzo, e ciò richiede la cooperazione (ovvero: firme crittografiche) di tutti e tre i partecipanti. Se Alice, Bob e Carol sono tutti d’accordo, le sei monete possono essere spese come stabilito, e questa sembrerà una qualsiasi transazione sulla rete Bitcoin. La caratteristica fondamentale è che il saldo non viene speso senza la collaborazione degli altri.

La seconda opzione principale consiste in realtà in diverse opzioni secondarie. Prima di inviare le loro monete alla pool di pagamento, Alice, Bob e Carol nascondono qualcosa all’interno dell’indirizzo Taproot: ad esempio includervi modi alternativi per inviare fondi dalla pool (cosa che potrebbe essere realizzata ad esempio facendo in modo che tutti e tre i partecipanti pre-firmino le transazioni che prendono determinati percorsi, il che richiederebbe una certa complessità di impostazione).

Se uno dei partecipanti sceglie di spendere le monete della pool tramite un percorso Taproot alternativo, egli invierà un importo corrispondente al suo saldo verso un indirizzo di sua scelta, che controlla. Utilizzando questo percorso alternativo, anche le monete residue però fuoriescono automaticamente, e ciò nelle modalità stabilite in fase di progettazione della pool di pagamento (presumibilmente ognuno riottiene la propria quota in un proprio wallet). In estrema sintesi: se un utente esce dalla pool, tutti escono dalla pool.

Una soluzione, sarebbe quella di inviare tutte le monete rimanenti ad una nuova pool di pagamenti, simile alla prima, tranne che per le mancanti monete dell’utente fuoriuscito. Questo design offrirebbe una migliore esperienza utente.

Per capire meglio cosa succede quando le monete rimanenti vengono inviate ad una nuova pool di pagamento, supponiamo che Alice, Bob e Carol scelgano l’opzione con la quale tutte le monete rimanenti vengono appunto inviate ad una nuova pool. In questo caso se Alice esce dalla prima pool di pagamenti, tre monete verranno inviate ad un indirizzo di sua scelta, mentre le altre tre monete verranno inviate ad una nuova pool di pagamenti condivisa tra Bob e Carol. Alice a quel punto ha di nuovo il controllo esclusivo sulle proprie monete, mentre non sarà cambiato molto per Bob e Carol. I due potranno ancora collaborare per spendere le tre monete rimanenti come desiderano, oppure uno dei due potrà uscire unilateralmente, proprio come aveva fatto Alice in precedenza.

Se Bob esce unilateralmente anche dalla seconda pool di pagamento, invierà due monete ad un indirizzo di sua scelta ed una moneta ad una pool di pagamenti ancora più recente (la terza) con solo Carol all’interno. (Ovviamente, in questo esempio specifico fatto con soli tre partecipanti originari, a questo punto, avrebbe più senso mandare le residue monete di Carol ad un indirizzo che appartiene esclusivamente a lei).

Cosa c’è di veramente interessante in Taproot

Quindi abbiamo capito che tutti i partecipanti possono ritirare individualmente il proprio saldo da una pool, oppure, se tutti sono d’accordo, spendere le monete al suo interno. È questa seconda opzione che consente effettivamente di sfruttare la dinamicità dellle pool di pagamenti. Finché tutti i partecipanti sono d’accordo, oltre a poter semplicemente riappropriarsi dei propri fondi, e pagare persone terze, possono anche fare qualcosa di più interessante: trasferire i loro fondi a versioni più recenti di pool di pagamento, con design completamente diversi.

Diciamo che Alice sta acquistando una nuova auto e vuole pagarla con un Bitcoin. Alice, Bob e Carol potrebbero quindi creare una transazione dal pool di pagamento che invia una moneta alla concessionaria di auto e invia le restanti cinque monete a un nuovo pool di pagamento che sembra uguale alla prima, tranne che questa volta Alice potrà uscire da essa unilateralmente solo con due monete, una in meno di prima.

Siccome la relativa transazione appare come una normalissima transazione della blockchain di Bitcoin, che è “esplorabile” da chi la osserva, il concessionario di automobili potrebbe concludere che Alice possedeva tutte e sei le monete, e ne abbia usata semplicemente una per acquistare l’auto, mantenendo le altre cinque come resto. Non avrebbe dunque la minima idea che alcune delle monete appartengano in realtà a Bob ed altre a Carol, e che gli stessi siano stati coinvolti nella transazione.

Ogni volta che Alice, Bob o Carol spendono monete, la transazione potrebbe provenire da uno qualsiasi di loro e nessuno al di fuori del pool di pagamenti potrebbe capirne la differenza.

Le pool di pagamento quindi non consentono solo di spendere semplicemente le monete, ma anche di offuscarne e di conseguenza “privatizzarne” l’utilizzo che ne viene fatto. Con identici meccanismi anche utenti completamente nuovi potrebbero unirsi alla pool di pagamento. Se Alice, Bob e Carol accettano di far partecipare Dave, i tre collaboreranno con Dave per creare una transazione che invii i fondi della pool assieme alle nuove monete di Dave verso una nuova pool di pagamenti, progettata per consentire anche a Dave di collaborare nelle scelte.

Inoltre, c’è l’ulteriore possibilità per i partecipanti della pool di pagamento di pagarsi a vicenda. Se Alice, ad esempio, pagasse a Bob una moneta, i tre potrebbero cooperare per inviare i fondi a un nuovo pool di pagamenti in cui Alice ha una moneta sottratta dal suo saldo e Bob una moneta aggiunta. Sulla blockchain, ancora una volta, sembrerebbe un pagamento normale e gli osservatori della blockchain non avrebbero la minima idea di chi abbia pagato chi e quanto. 

In un’idea nota come “Channel Factory”, questi tipi di pool di pagamento potrebbero essere utilizzati anche per ospitare canali Lightning, o altri protocolli Layer Two. Ciò potrebbe consentire di “avvolgere” qualsiasi tipo di livello di protocollo aggiuntivo, nascondendo così tutta la complessità sottostante sottoforma di semplicissime transazioni che sono del tutto identiche ad un banale “Alice paga Bob 1 moneta”.