Questo articolo riguarda un concetto tecnologico basato sull'aggiornamento del protocollo Taproot proposto. Se non hai ancora familiarità con le basi di come funziona Taproot, ti consigliamo di leggere prima questo spiegatore.
Taproot, un potenziale aggiornamento al protocollo Bitcoin proposto per la prima volta dal collaboratore di Bitcoin Core Gregory Maxwell, è nelle sue ultime fasi di sviluppo. La tecnologia consiste in una combinazione intelligente di trucchi crittografici che consentirebbero agli utenti di nascondere contratti intelligenti complessi all'interno di transazioni dall'aspetto normale: la complessità viene rivelata solo se le parti di un contratto non collaborano.
Facendo leva su questa idea, i contributori di Bitcoin Core tra cui (ma non limitati a) Jeremy Rubin, Antoine Riard, Gleb Naumenko e lo stesso Gregory Maxwell hanno speculato su un concetto generale denominato pool di pagamento, joinpool o coinpool. Questi pool - per ora continueremo a chiamarli pool di pagamento - consentirebbero a gruppi di utenti di condividere la proprietà delle stesse monete (tecnicamente: UTXO) registrate sulla blockchain di Bitcoin, consentendo a uno qualsiasi di questi utenti di effettuare (o ricevere) pagamenti con loro. Poiché il gruppo ei suoi singoli membri si "nascondono" in una struttura Taproot, tutti godono di maggiore privacy, flessibilità contrattuale intelligente e altri vantaggi ... e potenzialmente godono anche di questi vantaggi fuori catena, rendendo i pool di pagamento una nuova soluzione di Livello Due.
Sebbene le specifiche del design variano leggermente da una proposta di pool di pagamento all'altra, il concetto generale è lo stesso. Ecco l'idea di base ...
Condivisione di una moneta
Innanzitutto, per creare un pool di pagamenti, gli utenti combinano le loro (frazioni di) monete 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, rendendolo un pool di pagamenti con sei monete.
Sulla blockchain, l'indirizzo del pool di pagamento sembra un normale indirizzo Bitcoin, che ora contiene sei monete. Ma sotto la superficie, Alice, Bob e Carol hanno usato abilmente Taproot per assicurarsi che ognuno di loro mantenga il controllo della propria quota di monete nel pool di pagamenti. Alice può in qualsiasi momento richiedere tre monete dall'indirizzo, Bob può in qualsiasi momento rivendicarne due e Carol una.
Questo perché ci sono solo due opzioni principali per spendere monete dall'indirizzo.
La prima opzione è spendere direttamente dall'indirizzo, in termini tecnici il percorso chiave Taproot. Ciò richiede la cooperazione (ovvero: firme crittografiche) da tutti e tre i partecipanti. Se Alice, Bob e Carol sono tutti d'accordo, le sei monete possono essere spese come preferiscono, e questa sembrerà come qualsiasi altra transazione regolare sulla rete Bitcoin. Il trio può ad esempio decidere di rinviare i rispettivi saldi a singoli indirizzi: tre per Alice, due per Bob e uno per Carol. Ma se lo scegliessero, potrebbero anche collaborare per donare tutte e sei le monete a Julian, o spenderle in qualsiasi altro modo su cui potrebbero essere d'accordo. L'importante è che tutti e tre abbiano bisogno di partecipare, quindi il saldo di nessuno viene speso senza la propria collaborazione.
La seconda opzione principale consiste in realtà in diverse opzioni secondarie. Prima di inviare le loro monete al pool di pagamento, Alice, Bob e Carol hanno nascosto qualcosa nell'albero crittografico dietro l'indirizzo Taproot: includevano modi alternativi per inviare fondi dal pool di pagamento. (Attualmente, questo potrebbe essere realizzato facendo in modo che tutti e tre i partecipanti pre-firmino le transazioni da questi percorsi, il che richiederebbe una certa complessità per impostare tutte le opzioni e non si ridimensionerebbe molto bene; gli aggiornamenti del protocollo proposti potrebbero potenzialmente renderlo più facile in futuro .)
Se uno dei partecipanti sceglie di spendere le monete nel pool di pagamento attraverso un percorso Taproot alternativo, in genere invierà un importo corrispondente al saldo di quel partecipante a un indirizzo di sua scelta, come un indirizzo individuale che controlla. (Nel caso di Alice, tre monete al suo indirizzo, nel caso di Bob due al suo indirizzo e nel caso di Carol uno.)
Utilizzando questo percorso alternativo, anche le monete rimanenti vengono spese automaticamente. Ciò può essere fatto in diversi modi a seconda della progettazione del pool di pagamenti, offrendo diversi compromessi in termini di complessità e scalabilità.
La soluzione più semplice è inviare anche ad ogni altro partecipante la propria quota di monete, a un indirizzo di propria scelta. In altre parole: se un utente esce dal pool, tutti escono dal pool.
Una seconda soluzione, preferita da Riard e Naumenko, è inviare tutte le monete rimanenti a un nuovi pool di pagamenti, che assomiglia esattamente al primo pool di pagamenti, appena rimosso da tutto ciò che ha coinvolto l'utente ora uscito. Questo design offre la migliore esperienza utente, ma è il più difficile da scalare, soprattutto perché è necessario prepararsi per tutti i possibili scenari di uscita, inclusi tutti i possibili scenari di uscita per tutti i potenziali nuovi pool. La scalabilità potrebbe, tuttavia, essere ottenuta con un potenziale aggiornamento del protocollo Bitcoin ancora da nominare per garantire che le regole del pool di pagamenti precedente vengano trasferite a qualsiasi nuovo pool di pagamenti.
Rubin ritiene che questa seconda soluzione sia poco pratica e preferisce optare per qualcosa di intermedio tra la prima e la seconda soluzione: alcuni partecipanti ricevono immediatamente le loro monete a un indirizzo di loro scelta, altri partecipanti ricevono le loro monete inviate a un nuovo pool di pagamenti. Questo design offre un'esperienza utente meno ideale, ma scalerebbe meglio e il potenziale aggiornamento del protocollo OP_CHECKTEMPLATEVERIFY aiuterebbe a semplificare il design e ad aumentare ulteriormente la scala. (Le uscite avverrebbero tramite Tree Payments; questi tipi di pagamenti vengono esaminati ulteriormente in Questo articolo.)
(Ci sono più compromessi tra la seconda e la terza soluzione, ma i dettagli di tutti i pro e i contro esulano dallo scopo di questo articolo; leggi discussione sulla mailing list bitcoin-dev per specifiche.)
Per vedere cosa significa quando le monete rimanenti vengono inviate a un nuovo pool di pagamenti, supponiamo che Alice, Bob e Carol scelgano la seconda opzione, dove contro tutti i le monete rimanenti vengono inviate a un nuovo pool di pagamenti. Se in questo disegno Alice esce dal primo pool di pagamenti, tre monete vengono inviate a un indirizzo di sua scelta, mentre le altre tre monete vengono inviate a un nuovo pool di pagamenti tra Bob e Carol. Alice a quel punto ha di nuovo il controllo esclusivo sulle proprie monete, mentre non è cambiato molto per Bob e Carol. I due possono ancora cooperare per spendere le tre monete rimanenti come desiderano, oppure uno dei due può uscire unilateralmente, come aveva fatto Alice in precedenza.
Se Bob esce quindi unilateralmente dal secondo pool di pagamenti, invia due monete a un indirizzo di sua scelta e una moneta a un pool di pagamenti ancora più recente (il terzo) con solo Carol rimasta. (Ovviamente, in questo esempio semplificato, un progetto in cui quest'ultimo pool di pagamenti viene sostituito con un indirizzo scelto da Carol avrebbe in realtà più senso, ma questo è un dettaglio di implementazione.)
L'importante è che i partecipanti a un pool di pagamento possano collaborare per effettuare qualsiasi tipo di pagamento dal pool che desiderano, mentre ognuno di loro può in qualsiasi momento uscire con le proprie monete, lasciando agli altri partecipanti il controllo delle proprie.
Mettere il pagamento nel pool di pagamento
Quindi abbiamo stabilito che tutti i partecipanti possono ritirare individualmente il proprio saldo da un pool di pagamenti o, se tutti sono d'accordo, spendere dal pool. È questa seconda opzione che consente effettivamente qualcosa di intelligente: il pool di pagamenti può essere dinamico. Finché tutti i partecipanti sono d'accordo, non possono semplicemente ripagare i propri fondi o pagare altri (come Julian), ma possono fare qualcosa di ancora più interessante. Possono trasferire i loro fondi a versioni più recenti del pool di pagamenti, con design diversi.
Questo, ad esempio, consente a ciascuno di loro di spendere dalla piscina.
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 pagamenti che invia una moneta alla concessionaria di auto e invia le restanti cinque monete a un nuovi pool di pagamenti che sembra uguale al primo, tranne che questa volta Alice può uscirne solo unilateralmente con due monete, una in meno di prima.
La transazione, nel frattempo, assomigliava a qualsiasi altra normale transazione Bitcoin. Il concessionario di automobili (o le spie blockchain) potrebbe concludere che Alice possedeva tutte e sei le monete e ne usava semplicemente una per acquistare l'auto, mantenendo le altre cinque come resto. Non avrebbero idea che alcune delle monete appartengano a Bob e Carol, o che fossero coinvolti nella transazione.
La prossima volta, quando Bob effettua un pagamento e Alice e Carol collaborano, viene effettuato dallo stesso pool di pagamenti, ancora una volta sembra una normale transazione Bitcoin per il mondo esterno. Nell'iterazione risultante del pool di pagamenti, Bob può uscire con una moneta invece di due. Nel frattempo, le stesse spie blockchain potrebbero aver pensato che Alice stesse effettuando di nuovo un pagamento, confondendole ulteriormente. (E anche se le spie blockchain scoprissero in qualche modo che l'indirizzo è davvero un pool di pagamenti tra Alice, Bob e Carol, non potrebbero comunque dire quale dei tre ha effettuato l'ultimo pagamento.)
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 può dire la differenza.
I pool di pagamento non consentono solo di spendere. Se Alice vuole ricaricare il suo "saldo" nel pool di pagamenti, potrebbe farlo anche lei. Alice, Bob e Carol in questo caso collaborerebbero per spostare le cinque monete correnti in un nuovo indirizzo Taproot, a cui Alice nella stessa transazione invierebbe una moneta aggiuntiva da uno dei suoi indirizzi (individuali). Il nuovo indirizzo Taproot conterrebbe ancora una volta sei monete, tre delle quali appartengono ad Alice, come si evince dalla sua opzione di uscita unilaterale.
Allo stesso modo, anche utenti completamente nuovi potrebbero unirsi al pool di pagamento. Se Alice, Bob e Carol accettano di far partecipare Dave, i tre collaborano con Dave per creare una transazione che invia i fondi del pool di pagamento insieme alle nuove monete di Dave a un nuovo pool di pagamento, progettato per consentire anche a Dave di partecipare e uscire se avesse scelto così.
Inoltre, c'è la possibilità per i partecipanti all'interno del pool di pagamento di pagarsi a vicenda. Se Alice, ad esempio, pagasse a Bob una moneta, i tre potrebbero collaborare per inviare i fondi a un nuovo pool di pagamenti in cui Alice ha una moneta sottratta dal suo saldo e Bob ha una moneta aggiunta. Sulla blockchain, ancora una volta, sembrerebbe un pagamento normale e le spie blockchain non avrebbero idea di chi ha pagato chi o quanto. (Vale la pena sottolineare che Dave avrebbe potuto entrare in modo simile nel pool, ricevendo un pagamento interno da uno dei partecipanti esistenti.)
Con un po 'di complessità extra (e idealmente con almeno un aggiornamento del protocollo Bitcoin extra come noinput), i trasferimenti potrebbero anche essere completati fuori catena. Quando Alice paga Bob, tutti i partecipanti in questo caso creerebbero ugualmente una transazione spendendo fondi in un nuovo pool di pagamenti, ma questa transazione sarebbe condivisa solo tra loro, non trasmessa alla rete (a meno che qualcuno non tenti di imbrogliare). In questo modo, Alice, Bob e Carol potrebbero continuare ad aggiornare il loro equilibrio "internamente" e persino lasciare che Dave entrasse in piscina a un certo punto. Quando tutti accettano di chiudere il pool, possono creare una transazione finale che spende dal pool di pagamenti originale, assegnando a ciascuno il saldo più recente.
Simile a un'idea più vecchia nota come Fabbriche di canali, questi tipi di pool di pagamento potrebbero eventualmente essere utilizzati anche per ospitare canali Lightning, caveau o altri protocolli di livello due. Ciò può offrire la possibilità di "avvolgere" qualsiasi tipo di livello di protocollo aggiuntivo in tali pool, nascondendo così tutta la loro complessità in transazioni identiche e dall'aspetto regolare.