Acest articol este despre un concept tehnologic bazat pe upgrade-ul propus de protocol Taproot. Dacă nu sunteți încă familiarizat cu elementele de bază ale modului în care funcționează Taproot, vă recomandăm să citiți mai întâi acest explicator.
taproot, un potențial upgrade la protocolul Bitcoin propus pentru prima dată de colaboratorul Bitcoin Core, Gregory Maxwell, se află în stadiile sale târzii de dezvoltare. Tehnologia constă într-o combinație inteligentă de trucuri cripto care le-ar permite utilizatorilor să ascundă contracte inteligente complexe în cadrul tranzacțiilor cu aspect obișnuit - complexitatea este dezvăluită doar dacă părțile la un contract nu cooperează.
Folosind această idee, colaboratorii Bitcoin Core, inclusiv (dar fără a se limita la) Jeremy Rubin, Antoine Riard, Gleb Naumenko și însuși Gregory Maxwell au speculat despre un concept general denumit fonduri de plată, joinpools sau pool-uri de monede. Aceste pool-uri – ne vom menține să le numim pool-uri de plăți deocamdată – ar permite grupurilor de utilizatori să împartă dreptul de proprietate asupra acelorași monede (tehnic: UTXO) așa cum sunt înregistrate în blockchain-ul Bitcoin, permițând în același timp oricăruia dintre acești utilizatori să efectueze (sau să primească) plăți. cu ei. Pe măsură ce grupul și membrii săi individuali „se ascund” într-o structură Taproot, toți se bucură de mai multă confidențialitate, flexibilitate de contract inteligent și alte beneficii... și pot chiar se bucură de aceste beneficii în afara lanțului, făcând pool-urile de plăți o nouă soluție de nivel doi.
Deși specificul designului variază puțin de la o propunere de grup de plăți la alta, conceptul general este același. Iată ideea de bază...
Împărțirea unei monede
În primul rând, pentru a crea un grup de plăți, utilizatorii își combină monedele (fracțiile de) prin agregarea lor într-o adresă Taproot partajată între ei. Deci, să presupunem că Alice deține trei monede, Bob deține două monede și Carol deține o monedă, pentru un total de șase. Împreună, creează o tranzacție care trimite aceste monede la adresa comună, făcându-l un grup de plăți cu șase monede.
Pe blockchain, adresa pool-ului de plăți arată ca o adresă Bitcoin obișnuită, care deține acum șase monede. Dar sub suprafață, Alice, Bob și Carol au folosit inteligent Taproot pentru a se asigura că fiecare dintre ei rămâne în controlul propriei părți de monede din fondul de plăți. Alice poate oricând revendica trei monede de la adresă, Bob poate în orice moment să pretindă două și Carol una.
Acest lucru se datorează faptului că există doar două opțiuni principale de a cheltui monede de la adresa.
Prima opțiune este să cheltuiți direct de la adresă, în termeni tehnici Taproot key-path. Acest lucru necesită cooperare (adică semnături criptografice) din partea tuturor celor trei participanți. Dacă Alice, Bob și Carol sunt de acord, cele șase monede pot fi cheltuite oricum doresc, iar aceasta va arăta ca orice altă tranzacție obișnuită din rețeaua Bitcoin. Trio-ul poate decide, de exemplu, să-și trimită soldurile respective înapoi la adrese individuale: trei pentru Alice, două pentru Bob și unul pentru Carol. Dar dacă ar alege așa, ar putea, de asemenea, să coopereze pentru a dona toate cele șase monede lui Julian sau să le cheltuiască în orice alt mod asupra căruia ar fi de acord. Important este că toți trei trebuie să participe, astfel încât soldul nimănui nu este cheltuit fără propria cooperare.
A doua opțiune principală constă de fapt din mai multe subopțiuni. Înainte de a-și trimite monedele la pool-ul de plăți, Alice, Bob și Carol au ascuns ceva în arborele criptografic din spatele adresei Taproot: au inclus modalități alternative de a trimite fonduri din pool-ul de plăți. (În prezent, acest lucru ar putea fi realizat dacă toți cei trei participanți presemnează tranzacțiile de pe aceste căi, ceea ce ar necesita o oarecare complexitate pentru a configura toate opțiunile și nu se extind foarte bine; upgrade-urile de protocol propuse ar putea face acest lucru mai ușor în viitor .)
Dacă unul dintre participanți ar alege să cheltuiască monedele din grupul de plăți printr-o cale alternativă Taproot, de obicei ar trimite o sumă corespunzătoare soldului respectivului participant la o adresă pe care o alege, cum ar fi o adresă individuală pe care o controlează. (În cazul lui Alice, trei monede la adresa ei, în cazul lui Bob două la adresa lui și în cazul lui Carol una.)
Folosind această cale alternativă, monedele rămase sunt de asemenea cheltuite automat. Acest lucru se poate face în mai multe moduri, în funcție de designul pool-ului de plăți, oferind diferite compromisuri în ceea ce privește complexitatea și scalabilitatea.
Cea mai simplă soluție este să trimiteți tuturor celorlalți participanți și partea lor de monede, la o adresă la alegerea lor. Cu alte cuvinte: dacă un utilizator iese din bazin, toată lumea iese din bazin.
O a doua soluție, preferată de Riard și Naumenko, este trimiterea tuturor monedelor rămase către a nou pool de plăți, care arată exact ca primul pool de plăți, pur și simplu scos din orice care a implicat utilizatorul care a ieșit acum. Acest design oferă cea mai bună experiență de utilizator, dar este cel mai greu de scalat, cel mai important deoarece este necesar să vă pregătiți pentru toate scenariile de ieșire posibile, inclusiv pentru toate scenariile de ieșire posibile pentru toate grupurile noi potențiale. Cu toate acestea, amploarea ar putea fi atinsă cu o posibilă actualizare a protocolului Bitcoin, care nu a fost încă numită, pentru a se asigura că regulile din grupul de plăți anterior sunt transferate în orice grup de plăți nou.
Rubin consideră totuși că această a doua soluție este nepractică și preferă să opteze pentru ceva între prima și a doua soluție: unii participanți își primesc imediat monedele la o adresă aleasă de ei, alți participanți li se trimit monedele la un nou grup de plăți. Acest design oferă o experiență de utilizator mai puțin ideală, dar ar scala mai bine, iar potențiala actualizare a protocolului OP_CHECKTEMPLATEVERIFY ar ajuta la simplificarea designului și la creșterea scalarii și mai mult. (Ieșirile ar avea loc prin Tree Payments; aceste tipuri de plăți sunt explorate în continuare în acest articol.)
(Există mai multe compromisuri între a doua și a treia soluție, dar detaliile tuturor argumentelor pro și contra nu fac obiectul acestui articol; citiți discuție pe lista de corespondență bitcoin-dev pentru detalii.)
Pentru a vedea ce înseamnă când monedele rămase sunt trimise la un nou grup de plăți, să presupunem că Alice, Bob și Carol aleg a doua opțiune, unde toate monedele rămase sunt trimise la un nou grup de plăți. Dacă în acest design Alice iese din primul pool de plăți, trei monede sunt trimise la o adresă pe care o alege, în timp ce celelalte trei monede sunt trimise la un nou pool de plăți între Bob și Carol. În acel moment, Alice are din nou controlul exclusiv asupra propriilor monede, deși nu s-au schimbat atât de multe pentru Bob și Carol. Cei doi pot coopera în continuare pentru a cheltui cele trei monede rămase cum doresc, sau oricare dintre ei poate ieși unilateral, așa cum făcuse Alice înainte.
Dacă Bob iese apoi unilateral din al doilea pool de plăți, el trimite două monede la o adresă pe care o alege și o monedă la un pool de plăți și mai nou (al treilea) cu doar Carol rămas. (Desigur, în acest exemplu simplificat, un design în care acest ultim grup de plăți este înlocuit cu o adresă aleasă de Carol ar avea de fapt mai mult sens, dar acesta este un detaliu de implementare.)
Cea mai importantă concluzie este că participanții la un pool de plăți pot coopera pentru a efectua orice tip de plată din pool-ul pe care îl doresc, în timp ce oricare dintre ei poate în orice moment să iasă cu propriile monede, lăsând pe alți participanți controlul asupra lor.
Introducerea plății în grupul de plăți
Prin urmare, am stabilit că toți participanții își pot retrage individual soldul dintr-un grup de plăți sau, dacă toți sunt de acord, pot cheltui din grup. Această a doua opțiune este cea care permite de fapt ceva inteligent: pool-ul de plăți poate fi dinamic. Atâta timp cât toți participanții sunt de acord, ei nu pot doar să-și plătească banii înapoi sau să plătească pe alții (cum ar fi Julian), dar pot face ceva și mai interesant. Ei își pot muta fondurile în versiuni mai noi ale fondului de plăți, cu design diferite.
Acest lucru, de exemplu, îi permite pe oricare dintre ei să cheltuiască din piscină.
Să presupunem că Alice cumpără o mașină nouă și vrea să plătească pentru ea cu un bitcoin. Alice, Bob și Carol ar putea crea apoi o tranzacție din grupul de plăți care trimite o monedă la reprezentanța de mașini și trimite cele cinci monede rămase la un nou fond de plată care arată la fel cu primul, cu excepția că de această dată Alice poate ieși din el doar unilateral cu două monede, una mai puțin decât înainte.
Tranzacția, între timp, arăta ca orice altă tranzacție obișnuită cu Bitcoin. Dealerul de mașini (sau spionii blockchain) poate concluziona că Alice deținea toate cele șase monede și pur și simplu a folosit una pentru a cumpăra mașina și le-a păstrat pe celelalte cinci ca schimb. Nu ar avea idee că unele dintre monede aparțin lui Bob și Carol sau că au fost implicați în tranzacție.
Data viitoare, când Bob face o plată și Alice și Carol cooperează, aceasta se face din același pool de plăți, arătând din nou ca o tranzacție Bitcoin obișnuită pentru lumea exterioară. În iterația rezultată a pool-ului de plăți, Bob poate ieși cu o monedă în loc de două. Între timp, aceiași spioni blockchain ar fi crezut că Alice făcea din nou o plată, derutându-i și mai mult. (Și chiar dacă spionii blockchain și-ar da seama cumva că adresa este într-adevăr un grup de plăți între Alice, Bob și Carol, ei tot nu ar putea spune care dintre cei trei a făcut cea mai recentă plată.)
De fiecare dată când Alice, Bob sau Carol cheltuiesc monede, este posibil ca tranzacția să fi venit de la oricare dintre ei și nimeni din afara fondului de plăți nu poate face diferența.
Grupurile de plăți nu permit doar cheltuieli. Dacă Alice dorește să-și completeze „soldul” în fondul de plăți, ar putea face și asta. Alice, Bob și Carol ar coopera în acest caz pentru a muta cele cinci monede actuale la o nouă adresă Taproot, la care Alice ar trimite, în aceeași tranzacție, o monedă suplimentară de la una dintre adresele ei (individuale). Noua adresă Taproot va conține din nou șase monede, dintre care trei îi aparțin Alicei, așa cum se reflectă în opțiunea ei de ieșire unilaterală.
În același mod, utilizatorii complet noi s-ar putea alătura și ei la pool-ul de plăți. Dacă Alice, Bob și Carol sunt de acord să-l lase pe Dave să participe, cei trei cooperează cu Dave pentru a crea o tranzacție care trimite fondurile pool-ului de plăți împreună cu noile monede ale lui Dave la un nou pool de plăți, conceput pentru a-l lăsa pe Dave să participe și să iasă. dacă ar alege așa.
În plus, există opțiunea ca participanții din grupul de plăți să se plătească reciproc. Dacă Alice i-ar plăti, de exemplu, lui Bob o monedă, cei trei ar putea coopera pentru a trimite fondurile către un nou grup de plăți, unde Alice i-ar scădea o monedă din soldul ei și lui Bob are o monedă adăugată. Pe blockchain, din nou, ar arăta ca o plată obișnuită, iar spionii blockchain nu ar avea idee cine a plătit pe cine sau cât. (Este de remarcat faptul că Dave ar fi putut intra într-un mod similar în pool, primind o plată internă de la unul dintre participanții existenți.)
Cu puțină complexitate suplimentară (și, în mod ideal, cu cel puțin o actualizare suplimentară a protocolului Bitcoin, cum ar fi Fără intrare), transferurile ar putea fi chiar finalizate și în afara lanțului. Când Alice îl plătește pe Bob, toți participanții ar crea în acest caz o tranzacție cheltuind fonduri către un nou grup de plăți la fel, dar această tranzacție va fi partajată doar între ei - nu va fi difuzată în rețea (cu excepția cazului în care cineva încearcă vreodată să trișeze). În acest fel, Alice, Bob și Carol și-ar putea continua să își actualizeze balanța „intern” și chiar și-ar putea lăsa pe Dave să intre în piscină la un moment dat. Când toți sunt de acord să închidă grupul, pot crea o tranzacție finală care cheltuiește din grupul de plăți inițial, acordând fiecăruia cel mai recent sold.
Similar cu o idee mai veche cunoscută ca Fabrici de canal, aceste tipuri de pool-uri de plăți ar putea fi folosite în cele din urmă pentru a găzdui ele însele canale Lightning, seifuri sau alte protocoale Layer Two. Acest lucru poate oferi potențialul de a „împacheta” orice tip de strat de protocol suplimentar în astfel de pool-uri, ascunzând astfel toată complexitatea lor în tranzacții identice și cu aspect obișnuit.