Suntem interesați de subiectul anonimatului în criptomonede de mult timp și încercăm să urmărim dezvoltarea tehnologiilor în acest domeniu. În articolele noastre am discutat deja în detaliu principiile de funcționare în Monero, și, de asemenea, efectuat tehnologii existente în acest domeniu. Cu toate acestea, toate criptomonedele anonime de astăzi sunt construite pe modelul de date propus de Bitcoin - Unspent Transaction Output (denumit în continuare UTXO). Pentru blockchain-urile bazate pe cont, cum ar fi Ethereum, soluțiile existente pentru implementarea anonimatului și confidențialității (de exemplu, sau ) a încercat să reproducă modelul UTXO în contractele inteligente.
În februarie 2019, un grup de cercetători de la Universitatea Stanford și Visa Research eliberată „Zether: Către confidențialitate în lumea contractelor inteligente”. Autorii au fost primii care au propus o abordare pentru asigurarea anonimatului în blockchain-urile bazate pe cont și au prezentat două versiuni ale unui contract inteligent: pentru tranzacții confidențiale (ascunderea soldurilor și sumelor de transfer) și anonime (ascunderea destinatarului și expeditorului). Găsim tehnologia propusă interesantă și am dori să împărtășim designul acesteia, precum și să vorbim despre motivul pentru care problema anonimatului în blockchain-urile bazate pe cont este considerată foarte dificilă și dacă autorii au reușit să o rezolve pe deplin.
Despre structura acestor modele de date
În modelul UTXO, o tranzacție constă din „intrari” și „ieșiri”. Un analog direct al „ieșirilor” sunt facturile din portofel: fiecare „ieșire” are o anumită denumire. Când plătiți pe cineva (formați o tranzacție) cheltuiți una sau mai multe „ieșiri”, caz în care acestea devin „intrari” ale tranzacției, iar blockchain-ul le marchează ca fiind cheltuite. În acest caz, destinatarul plății tale (sau tu însuți, dacă ai nevoie de schimbare) primește „ieșirile” nou generate. Aceasta poate fi reprezentată schematic astfel:
Blockchain-urile bazate pe cont sunt structurate la fel ca contul dvs. bancar. Ei se ocupă doar de suma din contul dvs. și de suma transferului. Când transferați o sumă din contul dvs., nu ardeți nicio „ieșire”, rețeaua nu trebuie să-și amintească ce monede au fost cheltuite și care nu. În cel mai simplu caz, verificarea tranzacției se reduce la verificarea semnăturii expeditorului și a sumei din soldul acestuia:
Analiza tehnologiei
În continuare, vom vorbi despre modul în care Zether ascunde suma tranzacției, destinatarul și expeditorul. Pe măsură ce descriem principiile funcționării acestuia, vom observa diferențele dintre versiunile confidențiale și anonime. Deoarece este mult mai ușor să se asigure confidențialitatea în blockchain-urile bazate pe cont, unele dintre restricțiile impuse de anonimizare nu vor fi relevante pentru versiunea confidențială a tehnologiei.
Ascunderea soldurilor și a sumelor de transfer
O schemă de criptare este utilizată pentru a cripta soldurile și pentru a transfera sume în Zether . Funcționează după cum urmează. Când Alice vrea să-l trimită pe Bob b monede după adresă (cheia publică) Y, ea alege un număr aleatoriu r și criptează suma:
unde C - suma criptata, D - valoare auxiliară necesară pentru descifrarea acestei sume, G - un punct fix pe curba eliptică, înmulțit cu cheia secretă, se obține cheia publică.
Când Bob primește aceste valori, pur și simplu le adaugă la soldul său criptat în același mod, motiv pentru care această schemă este convenabilă.
În mod similar, Alice scade aceleași valori din soldul ei, doar ca Y folosește cheia dvs. publică.
Ascunderea destinatarului și expeditorului
Schimbarea „ieșirilor” în UTXO datează din primele zile ale criptomonedelor și ajută la ascunderea expeditorului. Pentru a face acest lucru, expeditorul însuși, atunci când face un transfer, colectează „ieșiri” aleatorii în blockchain și le amestecă cu ale sale. Apoi, el semnează „ieșirile” cu o semnătură inelă – un mecanism criptografic care îi permite să convingă verificatorul că monedele expeditorului sunt prezente printre „ieșirile” implicate. Monedele mixte în sine, desigur, nu sunt cheltuite.
Cu toate acestea, nu vom putea genera ieșiri false pentru a ascunde destinatarul. Prin urmare, în UTXO, fiecare „ieșire” are propria sa adresă unică și este legată criptografic de adresa destinatarului acestor monede. În acest moment, nu există nicio modalitate de a identifica relația dintre adresa unică de ieșire și adresa destinatarului fără a cunoaște cheile sale secrete.
În modelul bazat pe cont, nu putem folosi adrese unice (altfel va fi deja un model de „ieșiri”). Prin urmare, destinatarul și expeditorul trebuie să fie amestecați cu alte conturi din blockchain. În acest caz, din conturile mixte sunt debitate 0 monede criptate (sau se adaugă 0 dacă destinatarul este mixt), fără a modifica efectiv soldul lor real.
Deoarece atât expeditorul, cât și destinatarul au întotdeauna o adresă permanentă, devine necesar să se folosească aceleași grupuri pentru mixare atunci când se transferă la aceleași adrese. Este mai ușor să te uiți la asta cu un exemplu.
Să presupunem că Alice decide să aducă o contribuție la organizația de caritate a lui Bob, dar preferă ca transferul să rămână anonim pentru un observator extern. Apoi, pentru a se deghiza în câmpul expeditorului, intră și în conturile lui Adam și Adele. Și pentru a-l ascunde pe Bob, adăugați conturile lui Ben și Bill în câmpul destinatar. Făcând următoarea contribuție, Alice a decis să-i scrie pe Alex și Amanda lângă ea, iar Bruce și Benjen lângă Bob. În acest caz, atunci când se analizează blockchain-ul, în aceste două tranzacții există o singură pereche de participanți care se intersectează - Alice și Bob, care de-anonimizează aceste tranzacții.
Curse de tranzacții
După cum am menționat deja, pentru a vă ascunde soldul în sisteme bazate pe cont, utilizatorul își criptează soldul și suma transferului. Totodată, acesta trebuie să demonstreze că soldul din contul său rămâne nenegativ. Problema este că atunci când creează o tranzacție, utilizatorul construiește o dovadă privind starea curentă a contului său. Ce se întâmplă dacă Bob trimite o tranzacție către Alice și aceasta este acceptată înaintea celei trimise de Alice? Atunci tranzacția lui Alice va fi considerată invalidă, deoarece dovada soldului a fost construită înainte ca tranzacția lui Bob să fie acceptată.
Prima decizie care vine într-o astfel de situație este înghețarea contului până la efectuarea tranzacției. Dar această abordare nu este potrivită, deoarece pe lângă complexitatea rezolvării unei astfel de probleme într-un sistem distribuit, într-o schemă anonimă nu va fi clar al cui cont să blocheze.
Pentru a rezolva această problemă, tehnologia separă tranzacțiile de intrare și de ieșire: cheltuielile au un efect imediat asupra bilanţului, în timp ce încasările au un efect întârziat. Pentru a face acest lucru, este introdus conceptul de „epocă” - un grup de blocuri de dimensiune fixă. „Epoca” actuală este determinată prin împărțirea înălțimii blocului la dimensiunea grupului. Atunci când procesează o tranzacție, rețeaua actualizează imediat soldul expeditorului și stochează fondurile destinatarului într-un rezervor de stocare. Fondurile acumulate sunt puse la dispoziția beneficiarului numai atunci când începe o nouă „eră”.
Drept urmare, utilizatorul poate trimite tranzacții indiferent de cât de des sunt primite fonduri (în măsura în care soldul său îi permite, desigur). Mărimea epocii este determinată în funcție de cât de repede se propagă blocurile prin rețea și cât de repede o tranzacție intră într-un bloc.
Această soluție funcționează bine pentru transferurile confidențiale, dar în cazul tranzacțiilor anonime, așa cum vom vedea mai târziu, creează probleme serioase.
Protecție împotriva atacurilor de reluare
În blockchain-urile bazate pe cont, fiecare tranzacție este semnată de cheia privată a expeditorului, ceea ce convinge verificatorul că tranzacția nu a fost modificată și a fost creată de proprietarul acestei chei. Dar dacă un atacator care asculta canalul de transmisie interceptează acest mesaj și trimite exact același al doilea? Verificatorul va verifica semnătura tranzacției și se va convinge de paternitatea acesteia, iar rețeaua va șterge din nou aceeași sumă din soldul expeditorului.
Acest atac se numește atac de reluare. În modelul UTXO, astfel de atacuri nu sunt relevante, deoarece atacatorul va încerca să folosească ieșirile uzate, care în sine nu sunt valide și sunt respinse de rețea.
Pentru a preveni acest lucru, în tranzacție este construit un câmp cu date aleatorii, care se numește nonce sau pur și simplu „sare”. Când retrimite o tranzacție cu o sare, verificatorul caută să vadă dacă nonce a fost folosit înainte și, dacă nu, consideră tranzacția validă. Pentru a nu stoca întregul istoric al nonceselor utilizatorului în blockchain, de obicei, în prima tranzacție, acesta este setat egal cu zero, iar apoi mărit cu unu. Rețeaua poate verifica doar dacă nonceul noii tranzacții diferă de cea anterioară câte unul.
În schema de transfer anonim se pune problema validării non-urilor tranzacției. Nu putem lega explicit nonce-ul de adresa expeditorului, deoarece, evident, acest lucru de-anonimizează transferul. De asemenea, nu putem adăuga unul la numerele tuturor conturilor participante, deoarece aceasta poate intra în conflict cu alte transferuri în curs de procesare.
Autorii lui Zether propun să genereze nonce criptografic, în funcție de „epocă”. De exemplu:
Aici x este cheia secretă a expeditorului și Gepoch — un generator suplimentar pentru epocă, obținut prin hașarea unui șir de forma „Zether +”. Acum, problema pare să fie rezolvată - nu dezvăluim nonceul expeditorului și nu interferăm cu nonce-urile participanților neimplicați. Dar această abordare impune o limitare serioasă: un cont nu poate trimite mai mult de o tranzacție pe „epocă”. Această problemă, din păcate, rămâne nerezolvată și în prezent face ca versiunea anonimă a lui Zether, în opinia noastră, să fie greu potrivită pentru utilizare.
Complexitatea dovezilor de cunoaștere zero
În UTXO, expeditorul trebuie să dovedească rețelei că nu cheltuiește o sumă negativă, altfel devine posibilă generarea de monede noi din aer (de ce este posibil acest lucru, am scris într-una dintre cele anterioare ). Și semnează, de asemenea, „intrarile” cu o semnătură inelă pentru a dovedi că printre monedele care se amestecă există fonduri care îi aparțin.
În versiunea anonimă a blockchain-ului bazat pe cont, expresiile pentru dovadă sunt mult mai complexe. Expeditorul demonstrează că:
- Suma trimisă este pozitivă;
- Soldul rămâne nenegativ;
- Expeditorul a criptat corect sumele de transfer (inclusiv zero);
- Soldul de pe sold se modifică doar pentru expeditor și destinatar;
- Expeditorul deține cheia privată a contului său și se află de fapt pe lista expeditorilor (dintre cei implicați);
- Nonce utilizat în tranzacție este compus corect.
Pentru o demonstrație atât de complexă, autorii folosesc un amestec (unul dintre autori, de altfel, a luat parte la crearea lui) și , care se numesc gloanțe Sigma. Dovada oficială a unei astfel de declarații este o sarcină destul de dificilă și limitează foarte mult numărul de persoane care doresc să implementeze tehnologia.
Rezultatul?
În opinia noastră, partea lui Zether care aduce confidențialitate blockchain-urilor bazate pe cont poate fi folosită chiar acum. Însă, în acest moment, versiunea anonimă a tehnologiei impune restricții serioase asupra utilizării acesteia, iar complexitatea acesteia asupra implementării sale. Cu toate acestea, nu trebuie neglijat faptul că autorii l-au lansat cu doar câteva luni în urmă și poate că altcineva va găsi o soluție la problemele care există astăzi. La urma urmei, așa se face știința.
Sursa: www.habr.com