Ne-am interesat demult de subiectul anonimatului în criptomonede și am încercat să urmărim evoluția tehnologiilor din acest domeniu. În articolele noastre am analizat deja în detaliu principiile de funcționare în Monero, precum și am efectuat analize despre tehnologiile existente în acest domeniu. Cu toate acestea, toate criptomonedele anonime de astăzi se bazează pe modelul de date propus de Bitcoin — Unspent Transaction Output (UTXO). Pentru blockchain-urile bazate pe conturi, cum ar fi Ethereum, soluțiile existente pentru implementarea anonimatului și confidențialității (de exemplu, sau ) au încercat să reproducă modelul UTXO în contractele inteligente.
În februarie 2019, un grup de cercetători de la Universitatea Stanford și Visa Research au lansat „Zether: Spre confidențialitate în lumea contractelor inteligente”. Autorii au propus pentru prima dată o abordare pentru asigurarea anonimatului în blockchain-urile bazate pe conturi și au prezentat două variante de contracte inteligente: pentru tranzacții confidențiale (ascunderea soldurilor și sumelor transferurilor) și anonime (ascunderea destinatarului și expeditorului). Considerăm tehnologia propusă interesantă și ne-ar plăcea să împărtășim modul său de funcționare, precum și să discutăm despre de ce problema anonimatului în blockchain-urile bazate pe conturi este considerată foarte complicată și dacă autorii au reușit să o rezolve complet.
Despre structura acestor modele de date
În modelul UTXO, o tranzacție este formată din „intrări” și „ieșiri”. Analogia directă pentru „ieșiri” este bancnotele din portofelul dumneavoastră: fiecare „ieșire” are un anumit nominal. Când plătiți cuiva (formați o tranzacție), folosiți una sau mai multe „ieșiri”, care devin „intrări” ale tranzacției, iar blockchain-ul le marchează ca fiind utilizate. Destinatarul plății dumneavoastră (sau dumneavoastră, dacă aveți nevoie de rest) primește „ieșiri” nou generate. Poate fi ilustrat schematic astfel:
Blockchain-urile bazate pe conturi sunt structurate aproximativ ca un cont bancar. Acestea operează doar cu suma din contul dumneavoastră și suma transferului. Atunci când transferați o sumă din contul dumneavoastră, nu ardeți nicio „ieșire”, rețeaua nu trebuie să rețină ce monede au fost consumate și care nu. În cel mai simplu caz, verificarea tranzacției se reduce la verificarea semnăturii expeditorului și a sumei din soldul său:
Analiza tehnologiei
În continuare, vom discuta despre modul în care Zether ascunde suma tranzacțiilor, primitorul și expeditorul. Pe parcursul descrierii principiilor sale de funcționare, vom sublinia diferențele dintre varianta confidențială și cea anonimă. Deoarece este mult mai simplu să asiguri confidențialitate în blockchain-uri bazate pe conturi, unele dintre restricțiile impuse de anonimizare nu vor fi relevante pentru versiunea confidențială a tehnologiei.
Ascunderea soldurilor și sumelor transferurilor
Pentru criptarea soldurilor și sumelor transferurilor în Zether se folosește un sistem de criptare . Funcționează astfel. Când Alice vrea să-i trimită lui Bob b monede la adresa (cheia sa publică) Y, ea alege un număr aleatoriu r și criptează suma:
unde C — suma criptată, D — un valoare auxiliară necesară pentru decriptarea acestei sume, G — un punct fix pe o curbă eliptică, prin înmulțirea căruia cu cheia secretă se obține cheia publică.
Când Bob primește aceste valori, el pur și simplu le adaugă la soldul său criptat în același mod, ceea ce face ca acest sistem să fie convenabil.
În mod similar, Alice scade din soldul său aceleași valori, doar că folosește Y cheia sa publică.
Ascunderea destinatarului și expeditorului
Amestecarea „ieșirilor” în UTXO a apărut încă de la începuturile criptomonedelor și ajută la ascunderea expeditorului. Pentru aceasta, expeditorul însuși, atunci când efectuează un transfer, selectează aleatoriu „ieșiri” din blockchain și le amestecă cu ale sale. Apoi le semnează cu o semnătură în cerc — un mecanism criptografic care permite convingerea celor care verifică că printre „ieșirile” amestecate se află monedele expeditorului. Monedele amestecate, desigur, nu sunt cheltuite.
Cu toate acestea, pentru a ascunde destinatarul, nu putem genera „ieșiri” false. Prin urmare, în UTXO, fiecare „ieșire” are propria adresă unică, care este legată criptografic de adresa destinatarului acestor monede. În prezent, nu există nicio modalitate de a identifica legătura dintre adresa unică a „ieșirii” și adresa destinatarului, fără a cunoaște cheile sale secrete.
În modelul bazat pe conturi, nu putem folosi adrese unice (altfel ar deveni deja un model de „ieșiri”). Prin urmare, atât destinatarul, cât și expeditorul trebuie amestecați printre alte conturi în blockchain. În acest fel, conturile amestecate au un total de 0 monede cheltuite (sau se adaugă 0 — în cazul amestecării destinatarului), fără a le schimba efectiv soldul real.
Deoarece atât expeditorul, cât și destinatarul au mereu o adresă constantă, aici apare necesitatea, atunci când se realizează transferuri pe aceleași adrese, de a folosi aceleași grupuri pentru amestecare. Este mai ușor să analizăm acest lucru printr-un exemplu.
Să presupunem că Alice a decis să facă o donație la fondul caritabil al lui Bob, dar preferă ca această donație să rămână anonimă pentru un observator extern. Atunci, pentru a se masca în câmpul expeditorului, ea introduce și conturile lui Adam și Adele. Iar pentru a-l ascunde pe Bob — în câmpul destinatarului, adaugă conturile lui Ben și Bill. La următoarea donație, Alice a decis să adauge lângă ea conturile lui Alex și Amanda, iar lângă Bob — pe Bruce și Benjen. În acest caz, la analiza blockchain-ului, în aceste două tranzacții va exista o singură pereche de participanți suprapuse — Alice și Bob, ceea ce va deanonimiza aceste tranzacții.
Cursele tranzacțiilor
Așa cum am menționat, pentru a-și ascunde soldul în sistemele bazate pe conturi, utilizatorul își criptează soldul și suma transferului. În acest proces, el trebuie să dovedească că soldul de pe contul său rămâne non-negativ. Problema este că atunci când formează o tranzacție, utilizatorul construiește o dovadă în legătură cu starea sa curentă a contului. Ce se va întâmpla dacă Bob îi trimite Alinei o tranzacție, iar aceasta este acceptată înainte ca tranzacția Alinei să fie procesată? Atunci tranzacția Alinei va fi considerată invalidă, deoarece dovada soldului a fost construită înainte de acceptarea tranzacției lui Bob.
Prima soluție care vine în astfel de situații este înghețarea contului până la realizarea tranzacției. Dar această abordare nu este viabilă, deoarece, în afară de complexitatea soluționării acestei probleme într-un sistem distribuit, în schema anonimă va fi neclar ce cont trebuie blocat.
Pentru a rezolva această problemă, tehnologia separă tranzacțiile de intrare și cele de ieșire: cheltuirea fondurilor are un efect imediat asupra stării balanței, în timp ce veniturile sunt amânate. Pentru aceasta, este introdus conceptul de „epoci” - grupuri de blocuri de dimensiuni fixe. „Epoca” actuală este definită prin împărțirea înălțimii blocului la dimensiunea grupului. Procesând o tranzacție, rețeaua actualizează imediat balanța expeditorului, iar fondurile destinatarului sunt adunate într-un depozit. Fondurile acumulate devin disponibile pentru destinatarul plății doar la începutul unei noi „epoci”.
Ca rezultat, utilizatorul poate trimite tranzacții indiferent de cât de des primește fonduri (desigur, în limita balanței sale). Dimensiunea 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 ajunge într-un bloc.
Această soluție funcționează bine în cazul transferurilor confidențiale, dar cu tranzacțiile anonime, așa cum vom vedea mai departe, creează probleme serioase.
Protecție împotriva atacurilor de replay
În blockchain-urile bazate pe cont, fiecare tranzacție este semnată cu cheia privată a expeditorului, ceea ce îl convinge pe verificator că tranzacția nu a fost modificată și că a fost generată de proprietarul acestei chei. Dar ce se întâmplă dacă un atacator care a interceptat canalul de transmisie captează acest mesaj și trimite un al doilea identic? Verificatorul va compara semnătura tranzacției și va fi convins de autorul acesteia, iar rețeaua va deduce din nou aceeași sumă din balanța expeditorului.
Această atac se numește atac de replay. În modelul UTXO, astfel de atacuri nu sunt relevante, deoarece atacatorul ar încerca să utilizeze ieșirile deja cheltuite, ceea ce în sine nu este valid și este respins de rețea.
Pentru a evita asta, în tranzacție se încorporează un câmp cu date aleatoare, denumit nonce sau simplu „sare”. La trimiterea din nou a tranzacției cu „sare”, verificatorul verifică dacă acest nonce a fost folosit anterior și, dacă nu, consideră tranzacția valabilă. Pentru a nu păstra întreaga istorie a nonce-urilor utilizatorilor în blockchain, de obicei în prima tranzacție acesta este setat la zero și apoi este crescut cu unul. Rețeaua trebuie doar să verifice că nonce-ul noii tranzacții este diferit de cel anterior cu unul.
În schema anonimă de transferuri apare problema validării nonc-urilor tranzacțiilor. Nu putem lega nonc-ul din mod explicit de adresa expeditorului, deoarece, evident, acest lucru de-anonimizează transferul. De asemenea, nu putem adăuga o unitate la nonc-urile tuturor conturilor implicate, deoarece acest lucru ar putea conflictua cu alte transferuri aflate în procesare.
Autorii Zether propun generarea nonc-ului criptografic — în funcție de „epocă”. De exemplu:
Aici x — cheia secretă a expeditorului, iar Gepoch — generator suplimentar pentru epocă, obținut prin hasharea unei string de forma 'Zether + '. Acum, problema pare să fie rezolvată — nu dezvăluim nonc-ul expeditorului și nu intervenim în nonc-urile participanților neimplicați. Dar o astfel de abordare impune o restricție gravă: un cont poate trimite maximum o tranzacție într-o „epocă”. Această problemă, din păcate, rămâne nerezolvată și, în prezent, face ca versiunea anonimă a Zether, în opinia noastră, să fie cu greu utilizabilă.
Dificultatea dovezilor cu dezvăluire zero
În UTXO, expeditorul trebuie să demonstreze rețelei că nu cheltuie o sumă negativă, altfel devine posibilă generarea de monede noi din aer (de ce acest lucru este posibil, am scris într-unul din articolele anterioare ). De asemenea, acesta trebuie să semneze «intrările» cu o semnătură în cerc pentru a dovedi că printre monedele amestecate se află fonduri ce îi aparțin.
În versiunea anonimă a blockchain-ului bazat pe conturi, expresiile pentru dovezi devin mult mai complexe. Expeditorul dovedește că:
- Suma trimisă este pozitivă;
- Soldul rămâne non-negativ;
- Expeditorul a criptat corect sumele transferurilor (inclusiv zero);
- Soldul pe cont se modifică doar pentru expeditor și destinatari;
- Expeditorul deține cheia secretă a contului său și acesta este, într-adevăr, prezent pe lista expeditorilor (printre cei amestecați);
- Nonc-ul utilizat în tranzacție este compus corect.
Pentru o astfel de dovadă complexă, autorii folosește o combinație (unul dintre autori, apropo, a participat la crearea acesteia) și , pe care o numesc Sigma-bullets. Dovezile formale ale acestei afirmații sunt o sarcină destul de complexă și limitează semnificativ numărul celor care vor să se implice în implementarea tehnologiei.
Ce înseamnă în final?
În opinia noastră, partea Zether, care aduce confidențialitate blocchain-urilor bazate pe conturi, poate fi utilizată deja acum. Dar, în prezent, versiunea anonimă a tehnologiei impune restricții serioase asupra utilizării sale, iar complexitatea acesteia afectează implementarea. Totuși, nu trebuie să ignorăm că autorii au lansat-o cu doar câteva luni în urmă și, poate, altcineva va găsi o soluție pentru problemele existente astăzi. Așa se face știința.
Sursa: habr.com
