Tema anonimnosti u kriptovalutama nas zanima već duže vrijeme i nastojimo pratiti razvoj tehnologija na ovom području. U našim člancima već smo detaljno raspravljali o načelima rada
U veljači 2019. grupa istraživača sa Sveučilišta Stanford i Visa Research
O strukturi ovih modela podataka
U UTXO modelu, transakcija se sastoji od "ulaza" i "izlaza". Izravni analog "izlaza" su novčanice u vašem novčaniku: svaki "izlaz" ima neku denominaciju. Kada nekome platite (tvorite transakciju), trošite jedan ili više "izlaza", u kojem slučaju oni postaju "ulazi" transakcije, a blockchain ih označava kao potrošene. U tom slučaju, primatelj vaše uplate (ili vi sami, ako vam je potreban kusur) prima novogenerirane "izlaze". Ovo se shematski može predstaviti ovako:
Blockchaini temeljeni na računu strukturirani su slično vašem bankovnom računu. Oni se bave samo iznosom na vašem računu i iznosom prijenosa. Kada prenesete neki iznos sa svog računa, ne sagorijevate nikakve "izlaze", mreža ne mora pamtiti koji su novčići potrošeni, a koji nisu. U najjednostavnijem slučaju, provjera transakcije svodi se na provjeru potpisa pošiljatelja i iznosa na njegovom stanju:
Analiza tehnologije
Zatim ćemo govoriti o tome kako Zether skriva iznos transakcije, primatelja i pošiljatelja. Dok budemo opisivali principe njegovog rada, uočit ćemo razlike u povjerljivoj i anonimnoj verziji. Budući da je puno lakše osigurati povjerljivost u lancima blokova koji se temelje na računu, neka od ograničenja koja nameće anonimizacija neće biti relevantna za povjerljivu verziju tehnologije.
Skrivanje stanja i iznosa prijenosa
Shema šifriranja koristi se za šifriranje stanja i iznosa prijenosa u Zetheru
gdje C - šifrirani iznos, D - pomoćna vrijednost potrebna za dešifriranje ovog iznosa, G - fiksna točka na eliptičkoj krivulji, kada se pomnoži s tajnim ključem, dobije se javni ključ.
Kada Bob primi te vrijednosti, jednostavno ih dodaje svom šifriranom stanju na isti način, zbog čega je ova shema prikladna.
Slično tome, Alisa oduzima iste vrijednosti od svoje bilance, samo kao Y koristi vaš javni ključ.
Skrivanje primatelja i pošiljatelja
Miješanje "izlaza" u UTXO-u potječe iz ranih dana kriptovaluta i pomaže u skrivanju pošiljatelja. Da bi to učinio, sam pošiljatelj, prilikom prijenosa, prikuplja nasumične "izlaze" u blockchainu i miješa ih sa svojima. Zatim potpisuje "izlaze" prstenastim potpisom - kriptografskim mehanizmom koji mu omogućuje da uvjeri verifikatora da su kovanice pošiljatelja prisutne među uključenim "izlazima". Sami miješani novčići se, naravno, ne troše.
Međutim, nećemo moći generirati lažne rezultate kako bismo sakrili primatelja. Stoga, u UTXO-u, svaki "izlaz" ima svoju jedinstvenu adresu, a ona je kriptografski povezana s adresom primatelja ovih kovanica. Trenutačno ne postoji način da se identificira odnos između jedinstvene izlazne adrese i adrese primatelja bez poznavanja njezinih tajnih ključeva.
U modelu temeljenom na računu ne možemo koristiti jednokratne adrese (inače će to već biti model "izlaza"). Stoga primatelj i pošiljatelj moraju biti pomiješani među ostalim računima u blockchainu. U ovom slučaju, šifrirani 0 kovanica se tereti s miješanih računa (ili se dodaje 0 ako je primatelj mješovit), bez stvarnog mijenjanja njihovog stvarnog stanja.
Budući da i pošiljatelj i primatelj uvijek imaju stalnu adresu, postaje potrebno koristiti iste grupe za miješanje prilikom prijenosa na iste adrese. Lakše je ovo pogledati na primjeru.
Recimo da Alice odluči dati prilog Bobovoj dobrotvornoj organizaciji, ali radije želi da prijenos ostane anoniman za vanjskog promatrača. Zatim, kako bi se maskirala u polju pošiljatelja, ulazi i u račune Adama i Adele. A da biste sakrili Boba, dodajte račune Bena i Billa u polje primatelja. Dajući sljedeći doprinos, Alice je odlučila pored sebe napisati Alexa i Amandu, a pored Boba Brucea i Benjena. U ovom slučaju, kada se analizira blockchain, u ove dvije transakcije postoji samo jedan par sudionika koji se presijecaju - Alice i Bob, što de-anonimizira ove transakcije.
Transakcijske utrke
Kao što smo već spomenuli, da bi sakrio stanje u sustavima koji se temelje na računu, korisnik šifrira svoje stanje i iznos prijenosa. Pritom mora dokazati da stanje na njegovom računu ostaje neminusno. Problem je što prilikom kreiranja transakcije korisnik gradi dokaz o svom trenutnom stanju na računu. Što se događa ako Bob pošalje transakciju Alice, a ona bude prihvaćena prije one koju je poslala Alice? Tada će se Aliceina transakcija smatrati nevažećom, budući da je dokaz stanja izgrađen prije nego što je Bobova transakcija prihvaćena.
Prva odluka koja dolazi u takvoj situaciji je zamrzavanje računa dok se transakcija ne izvrši. Ali ovaj pristup nije prikladan, jer osim složenosti rješavanja takvog problema u distribuiranom sustavu, u anonimnoj shemi neće biti jasno čiji račun blokirati.
Kako bi riješila ovaj problem, tehnologija razdvaja dolazne i odlazne transakcije: potrošnja ima trenutni učinak na bilancu, dok primici imaju odgođeni učinak. Da biste to učinili, uvodi se koncept "epohe" - skupina blokova fiksne veličine. Trenutna "epoha" određena je dijeljenjem visine bloka s veličinom grupe. Prilikom obrade transakcije, mreža odmah ažurira stanje pošiljatelja i pohranjuje sredstva primatelja u spremnik. Akumulirana sredstva stavljena su na raspolaganje primatelju tek kada započne nova “era”.
Kao rezultat toga, korisnik može slati transakcije bez obzira na to koliko često prima sredstva (naravno, koliko mu to stanje dopušta). Veličina epohe određena je na temelju toga koliko brzo se blokovi šire mrežom i koliko brzo transakcija ulazi u blok.
Ovo rješenje dobro radi za povjerljive prijenose, ali kod anonimnih transakcija, kao što ćemo vidjeti kasnije, stvara ozbiljne probleme.
Zaštita od replay napada
U lancima blokova koji se temelje na računu, svaka transakcija je potpisana privatnim ključem pošiljatelja, koji uvjerava verifikatora da transakcija nije modificirana i da ju je kreirao vlasnik ovog ključa. Ali što ako napadač koji je slušao prijenosni kanal presretne ovu poruku i pošalje točno istu drugu? Verifikator će provjeriti potpis transakcije i uvjeriti se u njezino autorstvo, a mreža će ponovno otpisati isti iznos sa salda pošiljatelja.
Ovaj napad se naziva napad ponavljanja. U UTXO modelu takvi napadi nisu relevantni, budući da će napadač pokušati iskoristiti potrošene izlaze, što samo po sebi nije valjano i mreža ga odbija.
Kako bi se spriječilo da se to dogodi, polje s nasumičnim podacima ugrađeno je u transakciju, koje se naziva nonce ili jednostavno "sol". Prilikom ponovnog podnošenja transakcije sa soli, verifikator gleda je li nonce korišten prije i, ako nije, smatra transakciju valjanom. Kako se cijela povijest korisničkih jednokratnih brojeva ne bi pohranjivala u blockchainu, obično se u prvoj transakciji postavlja na nulu, a zatim se povećava za jedan. Mreža može samo provjeriti razlikuje li se nonce nove transakcije od prethodne jedan po jedan.
U shemi anonimnog prijenosa javlja se problem provjere jednokratnih transakcija. Ne možemo eksplicitno vezati nonce za adresu pošiljatelja, jer, očito, to de-anonimizira prijenos. Također ne možemo dodati jedan u nonce svih računa koji sudjeluju, jer to može biti u sukobu s drugim prijenosima koji se obrađuju.
Autori Zethera predlažu generiranje nonce kriptografski, ovisno o "epohi". Na primjer:
Ovdje x je tajni ključ pošiljatelja, i Gepoch — dodatni generator za epohu, dobiven hashiranjem niza u obliku 'Zether +'. Sada se čini da je problem riješen - ne otkrivamo nonce pošiljatelja i ne ometamo nonce neuključenih sudionika. Ali ovaj pristup nameće ozbiljno ograničenje: jedan račun ne može poslati više od jedne transakcije po "epohi". Ovaj problem, nažalost, ostaje neriješen i trenutačno čini anonimnu verziju Zethera, po našem mišljenju, teško prikladnom za korištenje.
Složenost dokaza bez znanja
U UTXO, pošiljatelj mora dokazati mreži da ne troši negativan iznos, inače postaje moguće generirati nove kovanice iz ničega (zašto je to moguće, napisali smo u jednom od prethodnih
U anonimnoj verziji blockchaina temeljenog na računu, izrazi za dokaz mnogo su složeniji. Pošiljatelj dokazuje da:
- Poslani iznos je pozitivan;
- Saldo ostaje nenegativan;
- Pošiljatelj je ispravno šifrirao iznose prijenosa (uključujući nulu);
- Stanje na stanju mijenja se samo za pošiljatelja i primatelja;
- Pošiljatelj posjeduje privatni ključ svog računa i on je zapravo na popisu pošiljatelja (među uključenima);
- Nonce korišten u transakciji ispravno je sastavljen.
Za tako složen dokaz autori koriste mješavinu
Rezultat?
Po našem mišljenju, dio Zethera koji donosi privatnost u blockchaine temeljene na računu može se koristiti upravo sada. Ali u ovom trenutku anonimna verzija tehnologije nameće ozbiljna ograničenja na njezinu upotrebu, a njezina složenost na njezinu implementaciju. No, ne treba zanemariti da su ga autori objavili tek prije nekoliko mjeseci, a možda će netko drugi naći rješenje za probleme koji postoje danas. Uostalom, tako se radi znanost.
Izvor: www.habr.com